Description

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:

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.