在被认为有害的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

Change some stuff

然后从分支“stable”中签出substr1,然后可以像这样合并变更集r5:

$ 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的一半。更糟糕的是,如果你回头看日志,它会显示:

$ 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个文件发生了更改。

------------------------------------------------------------------------
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

必须有人记住,或者注意到,变更集中只有一部分被合并了,其余的需要做。不使用子目录合并可以避免这个问题。

有时您真的不想合并以前的所有提交,而上面的场景正是您打算做的。在这种情况下,最好添加一个描述您意图的好提交消息。

另一个原因可能是合并到根目录限制了将在存储库中的文件夹/文件上设置的svn:mergeinfo属性的数量。

对于1.5之前的Subversion版本,合并子目录使得以后合并目录树的其余部分变得非常复杂。 如果合并了一个目录,SVN只需将该目录中所做的所有更改应用到另一个分支。如果您已经合并了一个子目录,然后尝试合并主目录,那么子目录中的所有更改都已经在目标分支中(因为您以前合并了它们)。SVN现在不知道这些更改来自于以前的合并,它只是看到在试图合并子目录时有一些“阻碍”的事情,导致了很多冲突。

为了避免这种情况,您必须注意只合并以前没有合并的目录,使整个过程更加复杂。您必须准确地记住已合并的子目录的哪些修订,并且只应用其余目录/修订的其余更改。这会让人困惑。总是合并整个分支使这变得容易得多。当前版本的Subversion在内部跟踪以前的合并,这样就可以避免这些问题。

提交子目录没有问题。对于SVN来说,这只是对存储库的一个正常的全局修订。在这个版本中,只有一个子目录发生了更改,但是对于SVN来说,它仍然是整个存储库的新版本,就像其他提交一样。

提交不应该有问题,但在合并中,SVN跟踪什么是合并的,什么不是合并的。

因此,我假设您希望在根目录下合并,以简化将来的合并(相对于SVN比较的数据集大小)。