【发布时间】：2011-02-23 18:35:20
【问题描述】：
我在这里征求意见。以下可能被认为是 SVN 特定的问题，或更一般的版本控制问题。
如果项目的源代码要在对应于发布的某个点进行分支，也许是为了维护工作，是否最好：
(a) 从标签分支，或
(b) 从标签复制的节点（例如在主干上）分支？
这两种方法的优缺点是什么？有关系吗？
谢谢。
【问题讨论】：
标签： svn tags branch version-control
【发布时间】：2011-02-23 18:35:20
【问题描述】：
我建议 (b)，因为这将允许您使用 svn 的合并跟踪轻松地将合并返回到主干（假设您在服务器和客户端都有 svn 1.5+）。如果您使用技术 (a)，则必须自己管理合并 - 假设您不从同一个分支进行多次合并，这还不错。鉴于您正在考虑从标签创建一个分支，这通常用于修补，您最终可能需要多次合并到您的主干线才能将这些补丁重新放入主干。
标签是及时拍摄“快照”或标记特定代码行（无论是主干还是分支）的里程碑的首选方式，只是为了从已标记为里程碑的源代码中快速构建特定里程碑或用于在里程碑之间轻松区分。除此之外，所有工作都在主干和分支之间完成。如前所述，您可以使用svn log 轻松找到复制标签的修订版/源。例如svn log --stop-on-copy -v tags/yourtag 会将最新复制的修订版放在输出的尾部。这允许您从创建标签的活动代码行的修订中创建分支。
【讨论】：
-
事实证明，您不必自己管理与 (a) 的合并；使用 mergeinfo. 从分支到主干的合并命令可以正常工作。唯一的小“问题”是主干上的合并信息除了分支修订信息外，还包含带有创建修订的标签 URL。那可能不是你想要的。另一方面，它可能不被认为是一个重大问题。 [我没有尝试过重新融入；只是一个“普通”的合并。]对我来说，（b）感觉像是做事的正确方式，但我仍然不坚信（a）实际上是错误的。
在我看来，如果我打算在以后添加和修补主项目，我会走 (a) 路线，如果我打算开发并行的东西，我会走 (b)。
【讨论】：
部分回答我自己的问题：
(a) 具有分支与特定发布或发布候选更明显关联的优势
(b) 具有与分支关联的主干修订更直接明显的优势
无论哪种方式，都可以从另一个建立一个，尽管从标签到达主干可能比从主干找到标签更容易。因此在这方面，(a) 似乎更可取。
另外：当将分支维护合并回主干时，(b) 似乎是更自然的选择。
我欢迎任何进一步的意见、想法或链接。
【讨论】：