使用源代码控制的一个常见场景是同时拥有一个开发分支和版本化发布分支。我们使用 CVS，以 HEAD 作为开发分支，以及一个名为 e.g. 的分支。 release-6-2 表示产品的当前版本。
新功能的开发只进入开发分支，但错误修复有时必须同时检查到开发分支和当前发布分支。这有时会变得非常乏味，因此我正在寻找实用的方法来完成此任务。
当要提交的文件在两个分支上同步时，我特别在寻找一种快速“提交到这些分支”的解决方案。
（我们使用 CVS 作为我们的源代码控制系统，因此任何 CVS 特定的答案都很好。但是，看看其他源代码控制系统是否可以提供更好的方法也很有趣。 在客户端，我们使用 Eclipse，所以 Eclipse 解决方案很好。但如果您有非 Eclipse 解决方案，那也没关系。）
【问题讨论】：
标签： eclipse version-control cvs branch
将您的修复应用到所需的最旧版本分支。然后将更改合并到下一个发布分支，依此类推，直到您从最后一个发布分支合并到 HEAD。
假设您的产品的最旧版本是 1.0，并且您还有 1.1 和 1.5 版本。下一版本的新功能正在添加到 HEAD。如果在 1.0 中发现错误，则将修复应用到 1.0 分支。从 1.0 合并到 1.1 分支。从1.1合并到1.5分支，最后从1.5分支合并到HEAD。
从一个分支合并到另一个分支比手动将修复应用到每个分支更好。
使用 CVS，您必须手动跟踪合并了哪些版本，以便在下次合并时不会包含相同的修订。
如果你改用 Subversion，从一个分支合并到另一个分支会更容易。 Eclipse 的 subversion 工具将跟踪您之前合并了哪些修订，从而大大简化了在两个分支之间进行重复合并的任务。
从 CVS 更改为 Subversion 很容易（ish）。你不会是第一个做出这种举动的人。
【讨论】：
就像awalshe说的，分支之间最好合并。要挑选合并，Pragmatic Version Control using CVS 中描述的方法非常好：
在更改前的分支-标记（PRE_FOO）中，进行更改并提交，更改后的标记（POST_FOO）。然后，在主干中，使用标签合并：
cvs up -j PRE_FOO -j POST_FOO
分支之间的合并在 SVN 中更加容易和安全，将整个 CVS 历史转换为 SVN 也很简单 - 请参阅 cvs2svn。您应该使用 SVN 1.5，或者 - 使用早期的 SVN 版本 - svnmerge。
【讨论】：