Version Control with Subversion - Login

Branching and MergingM .$ svn propget svn:mergeinfo ./trunk:1680-3305,3328$ svn commit -m "Block r3328 from being merged to the branch."…This technique works, but it's also a little bit dangerous. The main problem is that we're notclearly differentiating between the ideas of “I already have this change” and “I don't havethis change.” We're effectively lying to the system, making it think that the change was previouslymerged. This puts the responsibility on you—the user—to remember that thechange wasn't actually merged, it just wasn't wanted. There's no way to ask Subversion fora list of “blocked changelists.” If you want to track them (so that you can unblock themsomeday). you'll need to record them in a text file somewhere, or perhaps in an inventedproperty. In Subversion 1.5, unfortunately, this is the only way to manage blocked revisions;the plans are to make a better interface for this in future versions.Merge-Sensitive Logs and AnnotationsOne of the main features of any version control system is to keep track of who changedwhat, and when they did it. The svn log and svn blame commands are just the tools forthis: when invoked on individual files, they show not only the history of changesets that affectedthe file, but also exactly which user wrote which line of code, and when she did it.When changes start getting replicated between branches, however, things start to get complicated.For example, if you were to ask svn log about the history of your feature branch,it would show exactly every revision that ever affected the branch:$ cd my-calc-branch$ svn log -q------------------------------------------------------------------------r390 | user | 2002-11-22 11:01:57 -0600 (Fri, 22 Nov 2002) | 1 line------------------------------------------------------------------------r388 | user | 2002-11-21 05:20:00 -0600 (Thu, 21 Nov 2002) | 2 lines------------------------------------------------------------------------r381 | user | 2002-11-20 15:07:06 -0600 (Wed, 20 Nov 2002) | 2 lines------------------------------------------------------------------------r359 | user | 2002-11-19 19:19:20 -0600 (Tue, 19 Nov 2002) | 2 lines------------------------------------------------------------------------r357 | user | 2002-11-15 14:29:52 -0600 (Fri, 15 Nov 2002) | 2 lines------------------------------------------------------------------------r343 | user | 2002-11-07 13:50:10 -0600 (Thu, 07 Nov 2002) | 2 lines------------------------------------------------------------------------r341 | user | 2002-11-03 07:17:16 -0600 (Sun, 03 Nov 2002) | 2 lines------------------------------------------------------------------------r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines------------------------------------------------------------------------r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines------------------------------------------------------------------------But is this really an accurate picture of all the changes that happened on the branch?What's being left out here is the fact that revisions 390, 381, and 357 were actually the resultsof merging changes from the trunk. If you look at one of these logs in detail, the multipletrunk changesets that comprised the branch change are nowhere to be seen:$ svn log -v -r 390------------------------------------------------------------------------r390 | user | 2002-11-22 11:01:57 -0600 (Fri, 22 Nov 2002) | 1 lineChanged paths:M /branches/my-calc-branch/button.c105