12
4

4 回答 4

15

一种可能的解释是您可能会忘记更改集的某些部分。

如果您正在合并的更改集覆盖了您已签出的子目录之外的文件，那么您总是有可能忘记合并这些文件。

例如，如果您在主干上有这样的提交：

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：

$ 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

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

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

于 2009-04-16T20:33:46.963 回答
6

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

于 2009-04-20T11:33:52.733 回答
1

提交应该没有问题，但在合并中，SVN 会跟踪合并和未合并的内容。

因此，我假设您希望在根处合并以简化将来的合并（关于 SVN 比较的数据集大小）。

于 2009-04-16T20:35:00.140 回答
1

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

为避免这种情况，您必须注意仅合并您之前未合并的目录，从而使整个过程更加复杂。您必须准确记住您已经合并了哪些子目录的哪些修订，并且只应用剩余目录/修订的剩余更改。这可能会让人感到困惑。总是合并整个分支使这更容易。当前版本的 subversion 在内部跟踪以前的合并，因此可以避免这些问题。

提交子目录没有问题。对于 svn，这只是存储库的正常全局修订。在那个版本中，只有一个子目录会发生变化，但对于 svn，它仍然是整个存储库的新版本，就像任何其他提交一样。

于 2009-04-16T20:46:15.420 回答