I'm a big fan of subversion. Over the years, I've watched as subversion's branching and merging functionality has gotten easier and easier to use. Back in the day, merging in a branch was a multi-step process which included running svn log --stop-on-copy and having to scribble down revision numbers. For years now, though, this hasn't been the case. Merging usually Just Works. Here's the workflow of creating and merging a feature branch:
# make the branch! cd ...trunk... svn copy ^/trunk ^/branches/feature-foo # Go to work! cd ...feature-foo... vim bar.php # Merge the branch back in! svn merge ^/branches/feature-foo . svn commit
This all works great, except for one tiny detail. When you're back on the trunk and you run:
svn log bar.php
You only see the log entries for commits that happened on the trunk. The result: you see where you merged in feature-foo, but the actual changes you made to feature-foo aren't shown. In the case of a feature branch, there could be dozens of commits that aren't shown, yet the single line saying the branch was merged in, is shown.
One work around I've used is to re-check out the branch and run an svn log there, which works, but is a real hassle.
Every time I run into this issue I think I'll just have to take some time to write a script or something to get the full svn log for a file.
Today I realized I'd been massively over-thinking this. While svn merge was getting smarter, so was svn log. If I run:
svn log -g bar.php
subversion uses merge history to give a complete log of the file. -g is your friend.
It's amazing what happens when you read the manual.