SVN 工作流程 - 先有鸡还是先有蛋 - 在将 V1 与 V2 合并之前，我需要 V1 中的代码才能在 V2 上工作
我们的分布式团队（3 名内部开发人员和 3 名以上外部开发人员）使用 SVN 来管理网站的代码库。我们为每个次要版本（4.1.0、4.1.1、4.1.2 等）都有一个分支。我们有一个主干，当我们发布版本并发布到我们的网站时，我们会将每个版本合并到其中。
我们遇到的问题的一个例子是： 4.1.1 添加了一个新功能，我们将其称为“创建项目的能力”。 另一项功能取决于 4.1.1 中的功能，计划在 4.1.2 中添加，称为“向项目添加任务的能力”。
因此，在周一，我们说 4.1.1 已“关闭”并且需要进行测试。我们的远程开发人员通常会在此时开始处理 4.1.2 的功能/票据。本周我们将测试 4.1.1 并修复所有错误并将其提交回 4.1.1。然后，在周五左右，我们将标记 4.1.1，将其与 trunk 合并，最后将其与 4.1.2 合并。但是，在我们测试的 4-5 天中，4.1.2 没有 4.1.2 的一些新功能所依赖的 4.1.1 中的代码。
因此，添加“向项目添加任务的能力”功能的开发人员没有可以构建的“创建项目的能力”功能，并且必须执行一些文件复制恶作剧才能继续工作。
我们可以/应该做什么来顺利完成这个过程？
PS：如果之前有人问过这个问题，我深表歉意 - 我确实进行了搜索，但找不到我要找的内容。
Our distributed team (3 internal devs and 3+ external devs) use SVN to manage our codebase for a web site. We have a branch for each minor version (4.1.0, 4.1.1, 4.1.2, etc...). We have a trunk which we merge each version into when we do a release and publish to our site.
An example of the problem we are having is thus:
A new feature is added, lets call it "Ability to Create A Project" to 4.1.1.
Another feature which depends on the one in 4.1.1 is scheduled to go in 4.1.2, called "Ability to Add Tasks to Projects".
So, on Monday, we say 4.1.1 is 'closed' and needs to be tested. Our remote developers usually will start working on features/tickets for 4.1.2 at this point. Throughout the week we will test 4.1.1 and fix any bugs and commit them back to 4.1.1. Then, on Friday or so, we will tag 4.1.1, merge it with trunk, and finally, merge it with 4.1.2. But, for the 4-5 days we are testing, 4.1.2 doesn't have the code from 4.1.1 that some of the new features for 4.1.2 depend on.
So a dev who is adding the "Ability to Add Tasks To Projects" feature, doesn't have the "Ability to Create a Project" feature to build upon, and has to do some file copy shenanigans to be able to keep working on it.
What could/should we do to smooth out this process?
P.S. Apologies if this question has been asked before - I did search but couldn't find what I'm looking for.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
听起来您需要一个基于主干的分支 X，以及一个基于 X 的分支 Y。
您可以在 X 中开发一个功能，并开始对其进行测试。与此同时，您将 X 复制到新分支 Y，并在那里开发第二个功能。
最终X被合并到主干并被释放。然后，当您完成 Y 的工作时，您可以将其合并回 X 进行测试，然后合并到主干中进行发布。
您可以在这两个功能发布后重复此过程。下次你在 X 中完成一个功能，并且想要在它的基础上进行构建时，只需将其合并回 Y 中
即可。如果你这样做，请务必记住：
Sounds like you need a branch X based on trunk, and a branch Y based on X.
You can develop a feature in X, and start having it tested. In the meantime, you copy X to a new branch Y, and develop the second feature there.
Eventually X gets merged to trunk and released. Then when you're finished working on Y, you can merge it back into X for testing, and then into trunk for release.
You can repeat this process after both features are released. The next time you finish a feature in X, and you want to build on it, just merge it back into Y.
If you're doing this, it's important to remember:
我们这样做的方式是所有开发都发生在主干中。您甚至只需提交到主干，然后 4.1.1 所需的任何修复都会从主干合并到 4.1.1 分支。 4.1.2 的分支仅在 4.1.2 测试开始时创建 - 一旦 4.1.2 分支创建，工作将在主干中继续，如果 4.1.2 需要任何修复，它们将在主干中创建，然后合并到4.1.2.
我们很少在需要合并回主干（或其他任何地方，实际上）的分支中进行更改。
The way we do it is that all development happens in trunk. You only even commit to trunk and then any fixes required for 4.1.1 get merged from trunk to the 4.1.1 branch. The branch for 4.1.2 is only created when testing on 4.1.2 begins - once the 4.1.2 branch is made, work continues in trunk and if any fixes are required for 4.1.2, they are made in trunk and then merged into 4.1.2.
It's very rare that we ever make a change in a branch that needs to be merged back into trunk (or anywhere else, really).
我会将所有新提交放入主干，除非有理由将它们放在其他地方。例如，通过为 4.1.1 和 4.1.2 创建不同的分支，您的示例最好通过在分支之间进行合并来实现，然后这两个分支可能会合并回主干。哎呀！在我看来，这就是合并信息地狱。
以下是 Subversion 书中的一些基本建议：
http://svnbook .red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html
I would have all new commits go into the trunk unless there's a reason to put them somewhere else. By creating different branches for 4.1.1 and 4.1.2, for instance, your example is best approached by doing merges between branches, both of which might then be merged back to trunk. Yuck! That's mergeinfo hell, in my opinion.
Here's some basic advice from the Subversion book:
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html
我想有几种方法可以做到这一点。
但我的实践是，躯干始终保持稳定。
没有未完成的-不稳定的代码应该放入主干。如果要添加一个新功能并且需要几天甚至几周的时间，那么我会为其创建一个分支。完成后，分支看起来稳定并经过测试，它会再次合并到主干中，然后删除分支。
这样躯干就会保持稳定。实验代码始终是分支。
如果我出于某种原因改变主意并跳过完成了一半的项目，我就不必考虑后备箱。我只是删除分支......
I guess there are several ways to do it.
But I practice that the trunk is always stable.
No unfinished - unstable code should go into the trunk. If there is a new feature to be added and it takes days, maybe weeks, then I create a branch for it. When it is done, and the branch seems stable and tested, it gets merged into the trunk again, and the branch is deleted.
This way the trunk will stay stable. And experimental code is always i the branch.
If I for some reason change my mind and skip a half done project, I dont have to think about the trunk. I simply delete the branch....
一种方法是从 4.1.1 分支而不是从主干分支 4.1.2（当然也从主干分支 4.1.1）。
然后，您可以轻松地将 4.1.1 定期合并到 4.1.2 中，并且在发布时仍然能够将每个分支的简单合并回主干。
One approach is to branch 4.1.2 from 4.1.1 instead of from trunk (and of course 4.1.1 from trunk).
You can then easily merge 4.1.1 into 4.1.2 regularly and still be able to do the trivial merge back into the trunk for each branch when it is time to release.