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.
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.
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:
And you then have a checkout of subdir1 from your branch ‘stable’, then you could merge the change set r5 like this:
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:
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.
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.