svn - 多版本项目中是否需要主干

Question

我在一个项目中工作，其中一个已发布版本处于维护阶段，两个或多个版本同时处于开发阶段。

这就是对主干的需要产生怀疑的地方。

我已经阅读了 The Read Bean and others(Pragmatic Version Control with Subversion)中的 SVN 书籍，然后所有人都建议使用以主干为中心的开发模式。我不知道在我的情况下这是否适用，以及是否存在其他具有多版本发布周期且成功使用其他模式的项目。

为什么推荐以主干为中心的模式？版本分支离主干越来越远有什么问题吗？我这个架构与主干的集成有什么意义吗？

                                          /-----gamma-----/(3)---------->                                         /               /               /----beta---/(1)---/(2)--/---beta--------/--\              /           /      /                          \     /------------alpha--/------/---\                        \    /                                \                        \------------trunk--------------------(a)----------------------(b)------------------>

编辑:

当我说两个或多个开发版本时，我指的是具有递增功能级别的软件版本。在上面的图形中:

• alpha:功能 A。
• 测试版:功能 A + B。
• gamma:功能 A + B + C。

意味着所有分支的功能都包含在以后的分支中(通过同步合并)。分支在稳定性级别(旧 分支更稳定)和功能(年轻 分支具有新功能)方面有所不同。

编辑 2，在 Trident 回答后:

稳定版本的开发是在一个主干的分支中完成的，然后在稳定时合并回主干，所以主干包含所有稳定的变化，最终是更稳定的软件版本。

我现在问这个问题是因为我正在重新考虑整个项目的分支策略。

Answer 1

我要把你的图表重新整理一下:

                                          /-----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 的日志命令(如果您不使用 --stop-on-copy 开关)会将您从标记带到分支 beta 并返回到主干。

啊，你说，但是我如何才能看到发布 alpha 和发布 beta 之间的区别？在我的方案中，我可以查看主干的历史!

但是，如果您需要查看一个版本与另一个版本之间的所有更改，您可以轻松地在两个标签之间进行比较。而且，因为它们是标签，所以找到实际的发布版本要容易得多，而不是试图找出主干上的哪个版本代表您的哪个版本。

所以，你确实有一个后备箱，但你只是不这么调用它。