Subversion - 任何人都应该在主干之外进行开发吗？
使用 Subversion 时，开发人员应该在主干之外工作，还是应该仅将主干用于来自每个开发人员分支的合并并由持续集成服务监视？
When using Subversion, should developers be working off the trunk or should the trunk be only used for merges from each individual developer's branch and watched by a continuous integration service?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
取决于变化的范围有多大。 一般的良好实践是主干应该始终是可编译的，但这并不一定意味着开发人员不能在主干上进行小的更改/错误修复——毕竟，这是拥有工作副本的原因之一； 您可以确保在提交之前编译某些内容。
较大的更改或功能添加几乎总是应该被拉到分支中，直到它们准备好集成，以免干扰其他开发。
Depends on how extensive the changes are. A general good practice is that trunk should always be compilable, but that doesn't necessarily mean developers can't work on the trunk for small changes/bugfixes - after all, that's one of the reasons for having a working copy; you can make sure something compiles before committing it.
Larger changes or feature additions should almost always be pulled off into branch until they're ready for integration so as not to interfere with other development.
有两种基本策略：
稳定的主干 - 代码在分支中开发，仅在经过充分测试后才签入主干，并且从您使用的 在一定程度上是个人喜好的问题。
但除了其中任何一个之外，个人开发人员还应该使用
分支机构自己的实验发展。
所以像往常一样，没有明确的答案！
There are two basic strategies:
Which you use is to certain extent a matter of personal preference.
But alongside either of these, individual developers should be using
branches for their own experimental developments.
So as usual, no definite answer!
正如尼尔·巴特沃斯所说，这取决于； 存在几种有效的方法。
然而，我个人建议拥有一个稳定的主干，并在临时分支上进行所有主要开发。 （也就是说，只有一次提交就能完全完成的小的、独立的更改应该直接进入主干。）为了避免寿命较长的分支离主线太远，（自动）合并所有至少每天进入所有开发分支的主干。 哦，一切都应该由 CI 监控——不仅是主干，还包括所有开发分支。 特别是对于 Hudson，这很容易，并且产生的开销很少。
如果对我们如何应用它感兴趣，请参阅 这个答案。 （我不想重复太多......:)
我实际上会推荐这种方法，即使只有一个团队在代码库上工作，并且即使每个人都在开发相同的功能/改变。 为什么？ 嗯，因为根据我的经验（除非在您的环境中，诸如发布时间表、要求等之类的事情是非常可预测的），让您的主干始终处于可发布的状态绝对是值得的。
As Neil Butterworth said, it depends; several valid ways exist.
However, personally I would recommend having a stable trunk, and doing all major development on temporary branches. (I.e., only small, independent changes that will be completely done with a single commit should go directly to trunk.) To avoid longer-lived branches getting too far from the mainline, (auto)merge everything that goes into trunk to all the development branches, at least daily. Oh, and everything should be watched by CI — not just trunk but all development branches too. Especially with Hudson it's a snap and causes very little overhead.
If interested in how we've applied this, there are some more details in this answer. (I'd hate to repeat myself too much... :)
I'd actually recommend this approach even if it's just one team working on the codebase, and even if everyone is working on the same feature/change. Why? Well, because in my experience (unless things — like release schedules, requirements, and so on — are very predictable in your environment) it definitely pays off to have your trunk in a releasable shape, all the time.
我有开发人员创建项目分支或更改主干的请求/错误分支，然后合并回来，所以在某种程度上，是的，我有开发人员在主干上工作，但是进入“合并”分支的内容是通过一些构建来控制的控制工具或过程。
我认为这个问题很好地涵盖了这一点
I have developers who create project branches or change request/bug branches off of trunk, and then merge back, so in a way yes, I have developers working off of trunk, but what goes into "merge" branches is controlled through some build-control tool or process.
I think this is pretty well covered by this question
是的，那应该是您要发布的工作副本。 您的所有分支都应该是代码的先前发布版本。
yes, that should be your working copy for release. All of your branches should be previous release versions of your code.
这完全取决于您的发布时间表。 如果当前定期签入的所有工作都打算立即发布，则可以将它们全部签入一个区域，例如 trunk。 如果有一些工作将被推迟，而其他尚未完成的工作必须先出去，那么第一个出去的代码可以提交到主干，然后将下一个代码提交到它自己的分支中，反之亦然。
您应该发现合并和刷新分支可能会很麻烦，有时会出现问题。 因此自然而然地尝试尽量减少这种情况是有道理的。 源代码控制的总体理念是每个人都可以在一个地方工作。
通常，当您拥有较大的团队时，发布时间表是由子团队及其项目组织的，并且这些项目有自己的分支。
It depends entirely on your release schedule. If all the work currently being checked in periodically is intended for release at once, they can all be checked into one area, like the trunk. If there's some work which will be held back while other, as yet unfinished work, has to go out first, the first code to go out could be committed to trunk, and the next code in it's own branch, OR vice versa.
You should find that merging and refreshing branches can be a hassle where things occasionally go wrong. So naturally trying to minimize that would make sense. The overall idea of source control is that everyone can work in one place.
Often when you get larger teams, the release schedule is organized by sub-teams and their projects and these have their own branches.
是的。
将最新分支设为最新版本是没有任何意义的。 然后，你的主干就会比你的分支变得过时。
Yes.
it does not make any sense to make your latest branch your most recent release. Then, your trunk becomes outdated from your branches.
我认为如果你很敏捷并且在几周内以小增量发布，那么你应该在主干中开发。 这样，您就拥有了最新的主干，它会不断构建，可能会损坏，但很快就会得到修复，当您准备好发布时，标记它并发布它。 这样，就不会出现从分支合并的麻烦了。
我想我还想补充一点，如果你在分支机构中开发，你就不可能敏捷。 分支开发仅适用于瀑布。
I think if you are agile and release in small increments within a few weeks, you should develop in trunk. This way, you have the latest in trunk, it gets built constantly, may be it gets broken, but would get fixed soon and when you are ready to release, tag it and release it. This way, there is no headache of merging from branches too.
I think I'd also like to add that if you are developing in branches, you can't be agile. Developing in branches works only in waterfall.
在我的公司，我们采用稳定的主干开发模式，代码在分支上开发并经过充分测试，然后合并到主干上。
但我发现这种做法非常令人畏惧，因为验证团队通常需要几个月的时间才能充分测试功能分支。 因此，我们最终会让这些分支徘徊数月，然后才能将它们合并回主干。
另一方面是使用不稳定的主干开发，所有更改始终进入主干，但随后我们的验证团队开始抱怨他们对代码没有信心，因为每个人的更改总是在那里并且存在没有隔离。
因此，似乎这些方法都不是真正最佳的。 对于验证可能需要很长时间的团队来说，是否有更优化的方法？
In my company we have adopted stable trunk development model with code being developed and fully tested on branches before being merged up to the trunk.
But i am finding this practice pretty daunting because it often takes months for the validation team to get around to fully testing the feature branches. So we end up with these branches lingering around for months before we can merge them back into trunk.
The flip side of this would be to use unstable trunk development with all changes going into the trunk all the time, but then our validation team starts complaining that they don't have confidence in the code because everyone's changes are always in there and there is no isolation.
So seems like neither one of these approaches is really optimal. Is there a more optimal approach for a team where validation can take a really long time?
我认为您使用的工具也是一个重要因素。
I think the tools you use are a big factor here as well.
我今天正在开发我们产品的 3.0 版本，并将我的代码更改签入主干。 该版本的发布还需要几周时间。
一位同事正在试验一些可能会进入 4.0 的功能，但绝对不会进入 3.0。 她正在将她的东西存入一个单独的分支。 把这种东西托运到行李箱里是错误的。
另一位同事正在修复 2.5 版本中的错误，我们已经将该版本交付给客户。 出于显而易见的原因，他正在将它们签入 2.5 分支。
所以，回答标题问题（如果每个人都在主干上开发，我的答案是否定的。HTH
P.S.关于合并。我们可以选择性地将一些东西从 2.5 分支合并到主干，但不能从主干回到分支。主干和 4.0 分支之间的合并可以是双向的。
I'm working on a version 3.0 of our product today and checking in my code changes into the trunk. The release is still several weeks ahead.
A coworker is experimenting with some features that might make it into 4.0, but definitely not into 3.0. She is checking her stuff into a separate branch. It would be wrong to check in that kind of stuff into the trunk.
Another coworker is fixing bugs in version 2.5, which we already shipped to a customer. He is checking them into the 2.5 branch for obvious reasons.
So, to answer the headline question (Should everyone be developing off the trunk, my answer is no. HTH
P.S. about merging. We could selectively merge some stuff from 2.5 branch to the trunk later, but not from the trunk back to the branch. The merging between the trunk and the 4.0 branch can go both ways.
我几乎一直在基于主干开发的团队中工作——工作得很好。 我并不是说这是最好的主意或任何东西，只是如果它会让你被解雇的话，就不值得反对。
然而，我们的系统始终是可构建的，并且也经常使用 CI。 每个开发人员都必须了解更新/重建/重新测试/提交周期（并不是说它万无一失，但它工作得足够好）。
嗯，当我想到我们有多少软件实践“足够好”时，我很伤心。
I've almost always worked on teams that developed on the trunk--works fine. I'm not saying it's the best idea or anything, just not something that's worth opposing if it's going to get you fired.
However, our system is always buildble and often uses CI as well. Each developer must be aware of the update/rebuild/retest/commit cycle (not that it's foolproof, but it works well enough).
Hmph, it hurts when I think of how many of our software practices work "Well Enough".
有人认为应该要求开发人员在主干上工作。
如果你让它们分支，有些人会忍不住无限期地维护这些分支，并定期与主干交叉同步。 这将不可避免地导致复杂的合并操作，进而产生错误。
通过强迫每个人都到主干上，他们必须保持非常靠近头部，因此由于糟糕的合并而引入错误的风险会更小。 此外，由于每个人都运行最新的代码，因此他们更有可能注意到逐渐出现的错误，并且修复会更快地提交。
当然，有时需要单独上演大型功能，但在这种情况下可以进行特别批准的例外。
There's an argument to be made that developers should be required to work on trunk.
If you let them branch off, some will be tempted to maintain those branches indefinitely and cross-sync with trunk at regular intervals. This will inevitably lead to complicated merge operations, and these in turn produce bugs.
By forcing everyone onto trunk, they have to keep pretty close to the head, so there will be less risk of bugs being introduced with bad merges. Also, since everyone runs up-to-date code, they're more likely to notice bugs as they creep up, and fixes will get committed faster.
Ofcourse, sometimes a large feature needs to be staged separately, but in those cases a specially approved exception can be made.
我们的主干只是为了合并和修复紧急错误。 当我们有一个新项目时，我们对主干进行分支，在分支上进行开发，如果任何其他分支合并到主干中，则从主干进行变基，当我们准备好测试时，我们部署分支。
当测试OK后，我们合并到trunk，并发布到beta。
在合并之前，我们在主干上做了一个版本以避免出现问题。
测试版确定后，我们发布到产品版。
Our trunk is only to merge and fix urgency bugs. When we have a new project, we branch the trunk, develop over the branch, rebase from trunk if any other branch was merged into the trunk and when we are done ready to test, we deploy the branch.
When test is OK, we merge to trunk, and release to beta.
Before the merge, we do a version on the trunk to avoid problems.
After beta was OK, we release to prod.
我认为这实际上取决于您的运营规模。 最多 5-10 个开发人员，每个人都致力于主干应该没问题。 但当然每个人都应该记住，主干需要始终是可编译的。 如果他们正在进行的重大更改暂时无法编译，那么他们应该转移到分支。
I think it really depends on the scale of your operation. Up to maybe 5-10 developers everyone committing to trunk should really be OK. But of course everyone should keep in mind that the trunk needs to always be compileable. If they're working on major changes that won't compile for a while, then they should move off to a branch.
使用 Subversion 时，每个人都在主干之外工作是常见的做法。 如果特定的开发人员正在开发大型或“实验性”功能，那么明智的做法是为该工作创建一个单独的分支，稍后可以将其合并回主干。
虽然，您描述的方法（每个开发人员都有自己的分支）更接近 Git 比颠覆。 如果这是您喜欢的工作方式，我强烈建议您使用 Git。
使用 Git，无需使用某种持续集成服务器来监视单独的分支。 相反，每个开发人员都有自己的分支，他们可以随时将其合并回主分支。
When using Subversion, it's common practice for everyone to work out of the trunk. If a particular developer is working on a large or "experimental" feature, it can be wise to create a separate branch for that work, which can be merged back into the trunk later.
Although, the method you are describing, with each developer having their own branch, is closer to Git than Subversion. If this is the way that you prefer to work, I would highly recommend using Git instead.
With Git, it's not necessary to use some sort of continuous integration server to watch the separate branches. Instead, each developer has their own branch, which they can just merge back into the main branch whenever they want.
有多种方法可以使用版本控制系统进行并行开发。 您上面建议的方法没有任何问题 - 但每种方法都有优点和缺点。 我曾经以两种方式工作过。
开发主干并削减发布分支很好，但如果您需要执行紧急生产发布，您最终必须修补发布分支并再次发布 - 意味着在 CI 系统中构建一个分支。
在分支中工作并保留主干（使用持续集成系统进行监控）也很好，但可能会导致与多个分支中进行更改的开发人员发生冲突问题。
另请查看以下网站：
http://www.cmcrossroads.com/bradapp/acme /branching/
它讨论了并行开发的许多分支模式，包括：
There are a number of methods for working with version control systems for parallel development. There's nothing wrong with the one that you suggest above - but there are advantages and disadvantages attached to each. I've worked in both ways.
Developing off trunk and cutting release branches is fine, but if you need to perform an emergency production release you end up having to patch the release branch and releasing that again - means building a branch in your CI system.
Working in branches and preserving the main trunk (monitoring with a continuous integration system) is also fine, but can lead to conflict issues with developers in multiple branches making changes.
Take a look at the following site also:
http://www.cmcrossroads.com/bradapp/acme/branching/
It discusses a number of branching patterns for parallel development including: