4

我目前面临以下情况:

我有一个带有主干的 SVN 存储库,一些开发人员继续添加代码(正如它应该做的那样)

然后我们有不同的分支(见图)p1_test(一个测试系统)和p1_live(一个生产系统)。

我们想要的过程是每 X 天从主干(进程 v¹)更新 p1_test 分支。然后来自 p1_test 的工作副本中的“真实文件”将被更新 (v²)。

系统 p1_test 没有经过测试,每个错误修复都(或应该)提交到 p1_test 分支,并且 p1_test 系统更新(再次 v²)。同时,其他未参与 p1-cycle 的开发人员将继续添加到主干。这些更改不应集成到 p1_test 分支中(还)。

最后(当 p1_test 被认为是稳定的时,分支 p1_live 应该从 p1_test 分支更新,并且对 p1_test 所做的所有更改都应该重新集成到主干(v³)。

在给定的时间点 v⁴ 被执行,这意味着 p1_live 的工作副本从 p1_live 分支更新。

即使一切都应该经过良好测试,我们必须选择“热修复”p1_live 上出现的任何严重错误。在这种情况下,更改直接对 p1_live 分支进行,并且系统从该分支 (v⁵) 更新。

此过程必须与未知数量的 pX_test 和 pX_live 系统同时工作。

Svn 分支模式

这甚至可以使用svn吗?目前,我面临着许多不同修订号、冲突等问题。

是否有版本控制系统可以让我遵循给定的程序?

亲切的问候, Timetrick

4

2 回答 2

5

We use Subversion for a large active codebase with a similar usage pattern to yours. We have the standard trunk/branches/tags base hierarchy. In branches we have unstable, testing, and stable. We also have "user" branches with a folder per username in the branches folder. Tags are exactly how they should be: An untouchable snapshot.

trunk

branches/unstable
branches/testing
branches/stable
branches/userA/branch1
branches/userA/branch2
...

tags/stable/rNNNN
tags/stable/vN.N.N.N
...
  • With all my experience using Subversion, I have found it works so much better if code flows in one direction only. The exception is creating a branch from trunk, which is of course okay to merge changes back into trunk once the branch is complete (commonly termed "reintegrating" a branch).
  • If code cannot flow in one direction, then it must at least stay on one path. That means a branch of a branch should never reintegrate directly back into trunk, for example.
  • Our usage pattern follows that all active development, including bug fixes, always finds its way into trunk first, and then trunk is the update provider for the unstable, testing, and stable branches. (It would also be okay to follow a trunk -> unstable -> testing -> stable merge path, but we don't due to reasons specific to our testing/release process.)
  • If you have a fix for a specific branch, then make it there and do not plan to merge it back into trunk. My experience has discovered that is a great way to accidentally have an innocent branch update break code or even remove code from trunk that simply had not been provided to the branch, yet.

You might gather from my points that Subversion requires a process to really use it effectively as you want to (and we do), and to avoid those odd conflicts that leave you saying "now what?" Everything you are describing and trying to figure out sounds all too familiar to me regarding Subversion.

I have often considered if the hype around DVCS tools like Git or Mercurial not having these problems (at all??) would be worth the time it would take to migrate our repositories (hundreds) over. The only thing stopping me from trying is time constraints, but you might be in a better position to give one of those tools a try.

于 2012-09-19T15:18:19.283 回答
2

好吧,我换成GIT了。

感谢这篇精彩的博客文章,我启动并运行了它。(它完成了我需要它做的所有事情,甚至更多......)

于 2012-09-28T06:27:19.050 回答