Does Subversion merge diff or just update revision on unmodified files

Question

We have some feature branches that can get put on ice for a few weeks at a time. After making many changes in the trunk, is it best to merge the changes from trunk into the branches or drop the branch and create a new branch directly from the trunk and copy the changes from the starting branch into it.

The reason I ask is that for a merge SVN simply takes a diff of the trunk from last merge to head and applies that to the branch.

In many cases the changes in the trunk far outweigh the changes in the branch, so from the size of the diff it would make sense to drop the feature branch and create a new one with the feature branches changes patched in.

This is particularly an issue when a lot of PDF's are updated.

It seems like another way would be for SVN to realize that a file in the branch was never touched and therefore update the revision number it points to rather than blindly applying the diff.

From the output of Subversion it seems as if it is applying the diffs though.

Answer 1

I think the way you're using Subversion is probably incorrect (I've done this before to). What you need to do is merge a range of revisions into your trunk. Example:

Rev: 100 
/trunk

(Make a branch)

Rev:101 
/trunk (r100) 
/branch (r101)

(Lots of changes)

Rev: 200 
/trunk (r100)
/branch (r200)

Now what you need to do is to generate all the diffs between r100 and r200 and apply them to the trunk. Merge is a little misleading (like the documentation states). Your use case is a fairly common scenario which is covered in the documentation.

I don't think there's any best practise on whether to merge trunk->branch or branch->trunk. It's very dependant on how you want to work and your scenario. From the sounds of it, the feature branch would be more unstable the trunk. It would make sense to merge into trunk once you have the feature completed. In order to limit conflicts when you merge back into trunk, you can continuously merge from the trunk->branch.

Answer 2

It seems like another way would be for SVN to realize that a file in the branch was not touched and therefore update the revision number it points to. This would avoid the extra space for the diff.

AFAIK, applying diff don't take any significant extra space in subversion. If the diff is small, it should take merely the similar amount of space as just updating revision.

BTW, merging from trunk to branch ? It'd only make sense only if you plan to merge branch back to the trunk later.

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html

Answer 3

From the Subversion 1.6 CHANGES file:

identical files share storage space in repository (issue #2286)

So, it appears that even though the diff is applied, upon commit, the code should discover identical files and just use pointers to the first version of the files.