Blocking Changes

Sometimes there's a particular changeset that you don't want to be automatically merged. For example, perhaps your team's policy is to do new development work on /trunk, but to be more conservative about backporting changes to a stable branch you use for releasing to the public. On one extreme, you can manually cherrypick single changesets from trunk to the branch—just the changes that are stable enough to pass muster. Maybe things aren't quite that strict, though; perhaps most of the time you'd like to just let svn merge automatically merge most changes from trunk to branch. In this case, you'd like a way to mask a few specific changes out, i.e. prevent them from ever being automatically merged.

In Subversion 1.5, the only way to block a changeset is to make the system believe that the change has already been merged. You'll need to manually edit the svn:mergeinfo property on the branch and add the blocked revision(s) to the list:

$ cd my-calc-branch

$ svn propget svn:mergeinfo .
/trunk:1680-3305

$ svn propset svn:mergeinfo "/trunk:1680-3305,3328" .
property 'svn:mergeinfo' set on '.'

This technique works, but it's also a little bit dangerous. The main problem is that we're not clearly differentiating between the ideas of “I don't want this change” and “I don't have this change.” We're effectively lying to the system, making it think that the change was previously merged. This puts the responsibility on you—the user—to remember that the change wasn't actually merged, it just wasn't wanted. There's no way to ask Subversion for a list of “blocked changelists.” If you want to track them (so that you can unblock them someday.) you'll need to record them in a text file somewhere, or perhaps in an invented property. 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.