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