提交并合并认为有害的SVN子目录? [英] Commits and merges on SVN subdirectories considered harmful?

问题描述

我们的主要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.

但是，一位同事指出了对合并子目录的引用在具有Subversion的版本控制 (又称为"SVN书")中:

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.

提交和合并SVN子目录对发行分支有害吗?
短暂的功能分支呢?

Is committing and merging SVN subdirectories harmful for release branches?
What about short-lived feature branches?

推荐答案

一种可能的解释是，您可能会忘记变更集的一部分.

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:

r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines
Changed paths:
   M /trunk/subdir1/main.c
   M /trunk/subdir2/main.c

Change some stuff

然后从分支"stable"中签出subdir1，然后可以像这样合并变更集r5:

And you then have a checkout of subdir1 from your branch "stable", then you could merge the change set r5 like this:

$ svn co http://example.com/svn/branches/stable/subdir1
$ cd subdir1
$ svn merge -c 5 http://example.com/svn/trunk/subdir1 .
--- Merging r5 into '.':
U    main.c
$ svn ci -m"Merged r5 from trunk"

但是这只会合并修订版5的一半.更糟糕的是，如果您回头查看日志，现在将显示以下内容:

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:

$ svn log -g http://example.com/svn/
...
------------------------------------------------------------------------
r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines
Changed paths:
   M /trunk/subdir1/main.c
   M /trunk/subdir2/main.c
Merged via: r6

Change some stuff

因此，看来您已经合并了整个提交，而实际上您只合并了其中的一部分.当然，r6确实表明稳定分支上只有1个文件已更改.

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.

------------------------------------------------------------------------
r6 | rich | 2009-04-16 22:28:16 +0200 (Thu, 16 Apr 2009) | 1 line
Changed paths:
   M /branches/stable/subdir2
   M /branches/stable/subdir2/main.c

Merge revision 5 from trunk

有些人必须记住或注意到，变更集中只有一部分被合并，而其余部分则需要这样做.不使用子目录合并可以避免此问题.

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子目录?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！