SVN:每个客户都有分支会有问题吗?

Mat*_*att 1 svn branching-and-merging

我们有一个定制的CMS和许多想要用它构建的网站的客户.解决方案结构如下:

Libs
- Lib1
- Lib2
- etc
Plugins
- Plugin1
- Plugin2
- etc
MVC Web Project
Run Code Online (Sandbox Code Playgroud)

MVC Web项目包含管理主题,网站的布局和资产等等......对于每个客户来说,大部分内容都是相同的 - 只有少数文件会改变(主要是与主题相关的东西,配置文件等等) ).如果我们不得不每次都要将项目的副本放入不同的SVN存储库中,那将是一种浪费和维护的噩梦.

我以前从未使用过SVN分支和合并,但我理解这个概念.我想做的事虽然有点奇怪......让我解释一下:

我注意到SVN创建了"廉价拷贝"分支 - 所以它不会复制每个文件.我在考虑做这样的事情:

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
Run Code Online (Sandbox Code Playgroud)

我的想法是为每个客户建立一个分支,只有少数文件被更改,我希望,当有变化时,很容易将主干中的最新代码合并到每个客户分支.

我猜这不正常,但它可行吗?有没有人看到任何潜在的问题?

Dav*_*vid 5

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

我在许多公司看到过这种情况.

我从来没有见过一家公司很高兴他们做到了.


考虑一下......当您获得更多客户时会发生什么?维护代码库的复杂性呈指数级增长.无论何时进行更改,都必须将其合并多次.每当你修复一个bug,你就必须重新合并并重新测试那么多次.您必须手动跟踪哪些更改已提升到哪些客户分支.而这将是非常,非常具有诱惑力/容易为特定客户做一个"快速热修复",因为他们正在大声抱怨它,然后几乎立即忘掉它.

那么测试呢?质量保证是否准备单独重新测试每个分支?因为这正是这导致的地方.(另一种方法是测试一个分支,合并到另一个分支,并假设它工作.通常不是一个好主意,而是运送与测试的代码库不同的代码库.)

这个混乱变得很快.


我注意到SVN创建了"廉价拷贝"分支 - 所以它不会复制每个文件.

在此考虑期间忽略这一事实.磁盘空间不贵.如果为了节省几个字节的磁盘空间而增加维护复杂性,那么在业务层面,您所做出的决策反映出业务及其员工的时间比硬盘驱动器的价值低.对于一个企业来说,这是一个非常糟糕的地方.


对于每个客户来说,大部分内容都是相同的 - 只有少数文件会改变(主要是与主题相关的东西,配置文件等)

优秀.然后,能够管理这一点的一大步将是确切地定义什么是客户特定的,并将其与不是.在理想的世界中,客户特定的东西(也被认为是特定于环境或特定于部署的)可以在单个配置文件中定义.它可能比那更复杂,但这是你的目标.

您肯定希望避免客户特定的代码.相同的代码库应该满足每个客户,并且应该在该代码库之外定义自定义.这样,可以测试和验证单个代码库.

客户特定的配置可以存储在源代码管理中,通常与代码库并行,并作为构建/部署方案的一部分包含在内.那里不需要分支机构,每个客户都可以在某些自定义文件夹中拥有自己的文件夹.添加一个新客户只需要添加一个新的配置文件夹,最坏的情况是,在准备/打包系统进行发货时,将一个新的case语句添加到构建/部署脚本以从该文件夹中获取.


在我看来,使用分支(在我看来经常过度使用)来偏离代码库,而不是偏离部署目标.(虽然有些系统确实有像"dev"分支和"prod"分支这样的东西.这些是技术上的部署目标.这真的用作显式快照机制,而不是真正的分支机制.)