在 SVN 子目录上提交和合并被认为是有害的？
我们的主 SVN 项目根目录中有几个大型子项目。
在使用我们的发布分支时，我只提交和合并我的子项目，主要是因为它更快。
然而，一位同事指出对合并子目录的引用使用 Subversion 进行版本控制（又名“SVN 书籍”）：
- 对于长期发布分支（如中所述名为“常见分支模式”的部分），仅在分支的根目录上执行合并，而不是在子目录上执行合并。
不幸的是，这就是警告的范围。 链接部分也没有给出解释。
提交和合并 SVN 子目录对发布分支有害吗？
短暂的功能分支又如何呢？
We have several large subprojects inside our main SVN project root.
I commit and merge only my subproject when working with our release branches, mainly because it's faster.
However, a colleague pointed out this reference to merging subdirectories in Version Control with Subversion (a.k.a "The SVN Book"):
- For long-lived release branches (as described in the section called “Common Branching Patterns”), perform merges only on the root of the branch, not on subdirectories.
Unfortunately, this is the extent of the warning. The linked section does not give an explanation either.
Is committing and merging SVN subdirectories harmful for release branches?
What about short-lived feature branches?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一种可能的解释是您可能会忘记更改集的某些部分。
如果您要合并的更改集覆盖了您已签出的子目录之外的文件，那么您总是有可能忘记合并这些文件。
例如，如果您在主干上有这样的提交：
然后您从“稳定”分支中签出 subdir1，那么您可以像这样合并更改集 r5：
但这只会合并修订版 5 的一半。不过，如果您返回并查看日志，它现在会显示以下内容：
所以看起来您已经合并了整个提交，而实际上您只合并了其中的一些。 当然，r6 确实显示稳定分支上只有 1 个文件发生了变化。
有人必须记住或注意到，只有部分变更集被合并，其余部分需要执行。 不使用子目录合并可以避免此问题。
有时您确实不想合并所有先前的提交，而上述场景正是您想要做的。 在这种情况下，最好添加一条描述您意图的良好提交消息。
One possible explanation is that you could forget parts of a change set.
If the change sets that you are merging cover files that are outside the subdirectory that you have checked out, then there is always the possibility that you will forget to merge those files.
For example, if you have a commit like this on trunk:
And you then have a checkout of subdir1 from your branch "stable", then you could merge the change set r5 like this:
But this will only merge half of revision 5. Worse still, if you go back and look at the log, it will now show this:
So it looks like you've merged the whole commit, when in fact you have only merged some of it. Of course r6 does show that only 1 file has changed on the stable branch.
Someone has to remember, or notice, that only part of the change set got merged and the rest needs doing. Not using subdirectory merges avoids this problem.
There are times when you really don't want to merge all of a previous commit, and the above scenario is exactly what you intended to do. In that case, it is probably best to add a good commit message describing your intentions.
另一个原因可能是仅合并到根目录限制了将在存储库中的文件夹/文件上设置的 svn:mergeinfo 属性的数量。
Another reason for this could be that merging only to the root limits the number of svn:mergeinfo properties that are going to be set on the folders/files in your repository.
对于 1.5 之前的 subversion 版本，合并子目录会使以后目录树其余部分的合并变得非常复杂。
如果合并一个目录，svn 只是将该目录中所做的所有更改应用到另一个分支。 如果您已经合并了子目录，然后尝试合并主目录，则子目录中的所有更改都已经在目标分支中（因为您之前合并了它们）。 svn 现在不知道这些更改来自之前的合并，它只是在尝试合并子目录时发现有一些“阻碍”的东西，从而导致了很多冲突。
为了避免这种情况，您必须小心地只合并之前未合并的目录，从而使整个过程变得更加复杂。 您必须准确记住已合并的子目录的哪些修订版，并且仅应用剩余目录/修订版的剩余更改。 这可能会让人感到困惑。 始终合并整个分支使这变得更加容易。 当前版本的 subversion 在内部跟踪以前的合并，以便可以避免这些问题。
提交子目录没有问题。 对于 svn 来说，这只是存储库的正常全局修订版。 在该修订版中，只会在一个子目录中进行更改，但对于 svn 来说，它仍然是整个存储库的新版本，就像任何其他提交一样。
For subversion versions prior to 1.5, merging subdirectories made later merges of the rest of the directory tree really complicated.
If you merged a directory, svn simply applied all the changes made in that directory to the other branch. If you had already merged a subdirectory and then tried to merge the main directory, all the changes in the subdirectory were already in the target branch (since you merged them before). Svn now didn't know that these changes were from a previous merge, it just saw that there were things "in the way" when it tried to merge the subdirectory, resulting in lots of conflicts.
To avoid this you would have had to take care to only merge the directories that you hadn't merged before, making the whole process much more complicated. You had to remember exactly which revisions of which subdirectories you already had merged and only apply the remaining changes of the remaining directories/revisions. This can get confusing. Always merging the whole branch made this much easier. Current versions of subversion keep track of previous merges internally, so that these problems can be avoided.
Committing subdirectories is no problem. For svn this is just a normal, global revision of the repository. In that revision there will be only changes in one subdirectory, but for svn it's still a new version of the whole repository, just like any other commit.
提交应该不会有问题，但是在合并中 SVN 会跟踪合并的内容和未合并的内容。
因此，我假设您希望在根处合并以简化将来的合并（相对于 SVN 比较的数据集大小）。
Committing should not have a problem, but in merges SVN tracks what is and is not merged.
Therefore I assume you want to merge at the root to simplify future merges (in respect to the data set size being compared by SVN).