Fatal编程技术网
  • svn/
  • SVN：为每个客户设立分支机构会有什么问题吗？

SVN：为每个客户设立分支机构会有什么问题吗？

svn

SVN：为每个客户设立分支机构会有什么问题吗？,svn,branching-and-merging,Svn,Branching And Merging,我们有一个定制的CMS和许多客户谁想要用它建立一个网站。解决方案结构如下所示： Libs - Lib1 - Lib2 - etc Plugins - Plugin1 - Plugin2 - etc MVC Web Project trunk - code for main project branches - Customer1's Project - Customer2's Project - then some real dev branches of course tags - Vers

我们有一个定制的CMS和许多客户谁想要用它建立一个网站。解决方案结构如下所示：

Libs
- Lib1
- Lib2
- etc
Plugins
- Plugin1
- Plugin2
- etc
MVC Web Project

trunk
- code for main project
branches
- Customer1's Project
- Customer2's Project
- then some real dev branches of course
tags
- Version 1 (Generic Demo Project)
- Version 2 (Generic Demo Project)
- etc
MVCWeb项目包含管理主题、站点布局和资产等。。。其中的大部分内容对于每个客户都是相同的——只有少数文件会更改（主要是与主题相关的内容、配置文件等）。如果我们每次都要制作一份项目副本放入不同的SVN存储库，这将是一种浪费，也是维护的噩梦

我以前从未使用过SVN分支和合并，但我理解这个概念。我想做的事情可能有点奇怪。。。让我解释一下：

我注意到SVN创建了“廉价复制”分支，所以它不会复制每个文件。我正在考虑这样做：

Libs
- Lib1
- Lib2
- etc
Plugins
- Plugin1
- Plugin2
- etc
MVC Web Project

trunk
- code for main project
branches
- Customer1's Project
- Customer2's Project
- then some real dev branches of course
tags
- Version 1 (Generic Demo Project)
- Version 2 (Generic Demo Project)
- etc
我的想法是为每个客户建立一个分支，其中只有少数几个文件被更改，我希望在发生更改时，可以很容易地将最新代码从主干合并到每个客户分支

我猜这是不正常的，但它可行吗？有人认为这有什么潜在的问题吗

我的想法是为每个客户设立一个分支机构

我在很多公司都见过这种情况

我从未见过一家公司为他们的成功感到高兴

考虑一下。。。当你有更多的顾客时会发生什么？维护代码库的复杂性呈指数级增长。任何时候你做一个改变，你必须把它合并很多次。任何时候你修复一个bug，你都必须重新合并并多次重新测试。您必须手动跟踪哪些更改已升级到哪些客户分支机构。而且，为特定客户进行“快速热修复”将非常、非常、非常、容易，因为他们会大声抱怨，然后几乎立即忘记

那么测试呢？QA是否准备单独重新测试每个分支机构？因为这正是问题的症结所在。（另一种方法是测试一个分支，合并到另一个分支，并假设它可以工作。一般来说，发布不同于测试的代码库不是一个好主意。）

这一团糟很快就大了

我注意到SVN创建了“廉价复制”分支，所以它不会复制每个文件

在考虑的过程中忽略这一事实。磁盘空间并不昂贵。如果您只是为了节省几字节的磁盘空间而增加维护复杂性，那么在业务层面上，您所做的决策反映出业务及其员工的时间不如硬盘那么宝贵。对于一家企业来说，那是一个非常糟糕的地方

其中的大部分内容对于每个客户都是相同的-只有少数文件会更改（主要是与主题相关的内容、配置文件等）

好极了。那么，朝着能够管理这一点迈出的一大步就是准确定义哪些是特定于客户的，并将其与哪些不是区分开来。在理想情况下，特定于客户的内容（也称为特定于环境或特定于部署）可以在单个配置文件中定义。这可能比这更复杂，但这是你的目标

您肯定希望避免使用特定于客户的代码。相同的代码库应该满足每个客户的需求，定制应该在代码库之外定义。这样就可以测试和验证单个代码库

特定于客户的配置可以存储在源代码管理中，通常与代码库并行，并作为构建/部署场景的一部分包含。那里不需要分支机构，每个客户都可以在一些自定义文件夹中拥有自己的文件夹。然后，添加一个新客户只需添加一个新的配置文件夹，最坏的情况是，在准备/打包系统以进行装运时，向构建/部署脚本添加一个新的case语句，以便从该文件夹中获取

分支的使用（在我看来是过度使用）是为了偏离代码库，而不是部署目标。（虽然有些系统确实有“dev”分支和“prod”分支。从技术上讲，它们是部署目标。这实际上是用作显式快照机制，而不是真正用作分支机制。）

我的想法是为每个客户设立一个分支机构

我在很多公司都见过这种情况

我从未见过一家公司为他们的成功感到高兴

考虑一下。。。当你有更多的顾客时会发生什么？维护代码库的复杂性呈指数级增长。任何时候你做一个改变，你必须把它合并很多次。任何时候你修复一个bug，你都必须重新合并并多次重新测试。您必须手动跟踪哪些更改已升级到哪些客户分支机构。而且，为特定客户进行“快速热修复”将非常、非常、非常、容易，因为他们会大声抱怨，然后几乎立即忘记

那么测试呢？QA是否准备单独重新测试每个分支机构？因为这正是问题的症结所在。（另一种方法是测试一个分支，合并到另一个分支，并假设它可以工作。一般来说，发布不同于测试的代码库不是一个好主意。）

这一团糟很快就大了

我注意到SVN创建了“廉价复制”分支，所以它不会复制每个文件

在考虑的过程中忽略这一事实。磁盘空间并不昂贵。如果您只是为了节省几字节的磁盘空间而增加维护复杂性，那么在业务层面上，您所做的决策反映出业务及其员工的时间不如硬盘那么宝贵。对于一家企业来说，那是一个非常糟糕的地方

<