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