SVN正确使用分支和主干
我对 SVN 项目的主干和分支的正确使用有疑问。对于我团队的项目，我们每年创建 3 个主要版本，有时中间会创建一两个次要版本。在任何时候，我们都可能会积极开发 2 个甚至 3 个版本。我们一直在分支中进行所有开发，结构如下：
/branches/project1/2009.01
/branches/project1/2009.06
/branches/project1/2009.09
/branches/project1/2009.10
迄今为止，每当我准备为下一个版本创建分支时，我都会将当前分支的更改合并到主干，然后从主干创建新分支。然后，我通过主干合并来手动保持最新的开发分支与先前版本分支的错误修复保持同步。不会在主干上执行任何开发或提交（合并的提交除外）。 现在我想知道我到底需要这个行李箱做什么。直接从上一个发布分支创建下一个发布分支并将错误修复更新直接从一个分支合并到下一个分支会出现什么问题。我可以直接删除trunk下的项目吗？
所有 SVN 最佳实践文档似乎都表明使用主干进行开发，但对每个版本使用单独的分支对我来说似乎更容易，因为我们可以同时处理 2 或 3 个版本。我的 SVN 使用有什么技术问题吗？建议？
谢谢！
I have a question as to the proper use of the trunk and branches for my SVN projects. For my team's project we create 3 major releases each year and sometimes a minor release or two in between. At any point in time we may have active development on 2 or even 3 releases. We have been doing all development in branches with a structure like:
/branches/project1/2009.01
/branches/project1/2009.06
/branches/project1/2009.09
/branches/project1/2009.10
To date whenever I get ready to create a branch for the next release I have merged the changes from the current branch to the trunk and then I create the new branch from the trunk. I then manually keep the latest dev branches up to date with bug-fixes to the previous release branches by merges through the trunk. No development or commits are ever performed on the trunk (except for the commit for the merges).
Now I am wondering what I even need the trunk for at all. What would be wrong with just creating the next release branch directly from the previous release branch and merge bug fix updates directly from one branch to the next as well. Could I just delete the project under the trunk?
All the SVN best practices docs seem to indicate using the trunk for development but using separate branches for each release seems much easier to me since we can be working on 2 or 3 releases at one time. Is there any technical problem with my SVN usage? Suggestions?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不认为你的工作方式有任何问题。如果它对您和您的团队有效，那就太好了。保留主干的一个优点是所有分支都脱离主干，而不是最终导致每个新产品分支都挂在前一个产品分支上的更混乱的情况。如果您要绘制修订图，您会发现它很快就会变得复杂。
I don't think there are any problems at all with the way you are working. If it works for you and your team then that's great. One advantage of keeping the trunk is that all of your branches come off the trunk, rather than ending up with a more messy situation where each new product branch hangs off the previous product branch. If you were to draw the revision graph you would see that it would get complex very quickly.
我同意 the_mandriill - 你所做的事情没有任何问题，但总是质疑你是否可以做得更好也没有问题（至少在我看来）。
有一篇很棒的文章 cmcrossroads 它将为您提供有关不同方式的足够多的想法管理您的代码。
K
I agree with the_mandriill - there's nothing wrong with what you're doing, but there's also nothing wrong (IMO at least) of always questioning if you could do better.
There's a great article an cmcrossroads which will give you more than enough ideas about different ways of managing your code.
K
你的工作方式很好。目前，所有内容都通过主干进行，因此您有一个参考点来了解所有内容在哪里。不使用主干的问题是要充分了解错误的去向。对于主干来说，问题是线性的。如果没有主干，它就会呈指数级增长，因为您必须将每个分支与其他每个分支进行比较才能了解其中的内容。
就我个人而言，我不希望看到任何代码源自发布分支 - 首先在开发分支中进行修复，然后通过主干合并到发布分支。有时这是不切实际的，但合并历史记录总是可以被修改，使其看起来像是发生过的事情。一般来说，从开发分支到主干再到发布的稳定代码流是可以理解的。
这样做的原因是，您可以为每个修复分配一个主干修订号，并通过简单地检查每个版本针对主干的合并历史记录来跟踪该修订。您甚至可以将其制成表格，以准确查看已发布的修复程序。 （例如，请参阅我的答案此处）。
如果修复可以源自发布分支，那么这种比较就会变得更加困难。不过我想还是有可能的。但如果没有主干，你就必须将每个版本相互比较，这将变得更加困难。
The way you're working is fine. At the moment, everything goes through trunk, so you've got a single point of reference to know where everything is. The problem with not using a trunk is having solid knowledge of where a bug has gone. With a trunk, the issue is a linear one. Without a trunk, it becomes exponential, as you have to compare every branch against every other branch to see what's in them.
Personally I'd rather not see any code originate in the release branches - make fixes in dev branches first, then merge through trunk to the release branch. Sometimes this isn't practical, but the merge history can always be fiddled to make it look like that's what happened. In general, a solid flow of code from dev branches, through trunk and into releases is quite understandable.
The reason for this is that you can then assign a trunk revision number to every fix, and trace that revision by simply examining each release's merge history against trunk. You can even tabulate this to see exactly what fixes have been released. (For example, see my answer here).
If a fix can originate in a release branch, this kind of comparisson becomes much harder. Still possible though I suppose. But if there's no trunk, you have to compare every release against each other and it becomes a much harder proposition.