Question

Scenario:

1. Programmer creates a branch for project ‘foo’ called ‘my_foo’ at revision 5
2. Programmer makes multiple changes to multiple files as he works on the ‘my_foo’ feature.
3. At the end of each major step, say adding several new functions to a class, the programmer does an svn commit on the appropriate files therefore committing them to the branch
4. After several weeks and many commits later (each commit having a commit log describing what he did), the programmer merges the branch back into the trunk:

#Assume the following is being done from inside a working copy of the trunk:
svn merge -r 5:15 file:///path/to/repo/branches/my_foo

Hazzah! he’s merged all his changes back into trunk! There’s much rejoicing and drinking of Mountain Dew.

Now let’s say another programmer comes along a week later and updates their working copy from revision 5 to revision 15. “Wow”, they say. “I wonder what’s changed since revision 5”. The programmer then does an svn status on their working copy and they get something like this:

------------------------------------------------------------------------
r15 | programmer1 | 2010-03-20 21:27:04 -0400 (Sat, 20 Mar 2010) | 1 line

Merging Version 2.0 Changes into trunk
------------------------------------------------------------------------
r5 | programmer2 | 2010-02-15 10:59:55 -0500 (Mon, 15 Feb 2010) | 1 line

Added assets/images/tumblr_icon.png to trunk

What the heck happened to all the notes that the other programmer put in with all of his commits in his branch? Do those not get pulled over during a merge? Am I crazy or just forgetting something?

Answer 1

Answer is outdated, now that we have svn log -g.

---

No, you are not crazy. That is how it works, unfortunately.

The best you could do is include in the commit message for the merge the branch url and revision number, so that one could manually look up the revision log for that branch.
(The data is still there, of course).

However, you don’t know which of the changes have made it into the trunk, and which have not.

If there have been no or few changes on the trunk, it might be an option to do a reverse-merge (merge from trunk into branch) and then replace the trunk with the branch.
This kind of reasoning can also be done on individual subfolders (for example: replace the XML parser implementation subfolder from the branch, keep the rest).
Replacing folders (with svn delete, svn copy) will keep the revision history.

For files that were newly added during the merge, their revision history can be copied over from the branch, if you used the svn copy command. Not sure if the merge command includes support for this, though.

It might be interesting to know if there is a tool for svn that does a “rebase” (as in git or mercurial). That would create individual commits for every change on the branch. On the other hand, maybe individual commits are too much clutter.

Best recommendation I can give is to use a good UI, such as Trac, that makes it easy to inspect the revision history, so you can look at what happened on the branch.