Commits and merges on SVN subdirectories considered harmful?

岁酱吖の 提交于 2019-11-30 06:55:53

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

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"

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

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.

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.

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.

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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!