以下是该方案：
我们有一个源代码树，在任何给定时间都有多个开发人员在多个分支上工作。
我们还有一个这个源代码树的“自定义”副本，其差异（几乎）永远不会回到主要来源。这方面的发展是持续的，但变化要少于主要分支上的变化。
自定义版本需要与主源中的更改保持同步，同时保持自定义。
目前我们处理此问题的方式如下：
主要版本（称为1.2b）从主源树分支。自定义版本（称为1.2b.custom）从1.2b开始分支。来自先前自定义版本（1.2a.custom）的更改将合并到1.2b.custom中。根据需要，1.2b的更改将合并到1.2b.custom中。
冲洗，重复，目前正在进行第10次？自从我来到这里以来的迭代。
这可以“正常” - 但它会导致很多合并冲突，每个，单个，时间我们创建一个新的自定义版本。它还具有历史“丢失”的效果 - 查看1.2b.custom分支上的文件的历史记录显示1.2b.custom更改的历史记录，1.2a.custom merge ，但不是1.2a.custom分支上的实际提交。此外，它限制了对自定义分支进行更改的能力，因为无法在自定义内容上进行并行开发（即：在保留/修复当前版本上的错误的同时为下一个版本工作）
我正在寻找有关如何更好地处理这个问题的建议。我曾经想过的一个想法是选择一个点并将自定义“分叉”到它自己的主干中，仍然会出现从主要（分支或主干）合并变化的问题 - ＆gt;自定义主干，但我认为这“修复”了历史，并允许在自定义上进行并行开发。我可以浏览的其他想法或资源？
感谢。
答案 0 :(得分：1)
听起来你应该将主树看作是供应源代码的供应商。 subversion项目有a good discussion如何管理它。
答案 1 :(得分：0)
只是在这里集思广益，如果这与OP或PanCrit已提出的内容相同，请道歉......
这似乎应该如何运作：
^ ^ | release | |______|______| | | | | | release | |______|______| | | | | | | trunk custom
发布版由来自主干的代码和来自自定义分支的代码组成，每个版本在发布后都会继续存在。