Die*_*rán 3 svn version-control project-management
我在一个项目中工作，其中一个维护版本已发布，而同时两个或多个版本正在开发中。
这就是人们对后备箱需求的怀疑。
我已经阅读了Read Bean和其他书籍（带有Subversion的实用版本控制）中的SVN书，然后所有这些都建议使用以中继为中心的开发模式。我不知道这种情况是否适用，是否存在具有成功使用其他模式的多版本发布周期的其他项目。
为什么推荐以干线为中心的模式？版本分支在主干中越来越远是否有任何问题？我这个模式与树干的集成有什么意义吗？
/ -----伽玛----- /（3）---------->
///
/ ---- beta --- /（1）--- /（2）-/ --- beta -------- /-\
///
/ - - - - - - α - / - - - / - -\ \
/ \ \
------------树干--------------------（a）-------------- --------（b）------------------>
编辑：
当我说两个或多个开发版本时，我指的是具有递增功能级别的软件版本。在图形以上：
意味着分支的所有功能都包含在以后的分支中（通过同步合并）。树枝在稳定的水平不同（较旧的分支更稳定）和功能（幼枝有新的功能）。
编辑2，TridenT回答后：
稳定版本的开发在主干的分支中完成，然后在稳定时合并回主干，因此主干包含所有稳定的更改，最后是软件的更稳定版本。
我现在问这个问题是因为我正在重新考虑整个项目的分支策略。
我将拿您的图表进行重新组织：
/-----gamma-----/(3)---------->
/ /
/----beta---/(1)---/(2)--/---beta--------/--\
/ / / \
/------------alpha--/------/---\ \
/ \ \
------------trunk--------------------(a)----------------------(b)------------------>
首先，删除trunk，因为您没有使用它。是的，您正在重新合并到主干中，但是您永远不会从中取出代码。相反，beta来自alpha和gamma来自beta。还可以省去所有合并到您从未真正使用过的代码行中的精力：
/-----gamma-----/(3)---------->
/ /
/----beta---/(1)---/(2)--/---beta--------/
/ / /
/------------alpha--/------/
/
trunk
现在，让我们整理一下图表，使主要的开发思路变得简洁明了：
trunk-alpha-------beta-----------------------gamma-------------------------->
\ / / \ /
\---alpha-/------/ \---beta-------/
最后，翻转所有内容
/-alpha-\-----\ /--beta-------\
/ \ \ / \
trunk------/--(beta)---\-----\--------/-(gamma)---------\------(gamma)-------->
有你的行李箱！
我知道你在做什么 您不是在主干上编码，因为主干应该代表您的版本。在原始图中，主干上有两个版本。点（a）将分支alpha合并回主干，点（b）将分支beta合并回主干。这代表了您的Release alpha和Release beta。
但是，这就是标签的用途！您在发布上创建标签，标签现在代表您的发布。而且，最好使用标签来保留文件的历史记录。
假设您转到（b）点的行李箱并记录了特定文件。您在（b）点看到该文件，并且在（a）点看到另一个版本。但是，您不知道在（a）点和（b）点之间如何更改该文件。实际上，您甚至都不知道谁负责特定更改。
但是，如果您在分支上做了一个标记，而不是将代码合并回主干，则将看到该文件的整个历史，一直到文件的第一个版本。Subversion的log命令（如果您不使用该--stop-on-copy开关）将把您从标签下移到分支beta，然后再回到主干。
啊，您说，但是我如何看待发行版alpha和发行版beta之间的区别？在我的计划中，我可以查看行李箱的历史！
但是，如果您需要查看一个版本与另一个版本之间的所有更改，则可以轻松地在两个标签之间进行比较。而且，因为它们是标签，所以找到实际的发行版本要容易得多，而不是试图找出主干上的哪个版本代表您的哪个发行版本。
因此，您确实有一个行李箱，但是您别这样称呼它。