Re: merge tracking use cases

On Fri, 30 Nov 2007, Justin Erenkrantz wrote:

> On Nov 30, 2007 4:02 PM, Daniel Rall <dlr@collab.net> wrote:
> > Ignoring some bugs in what we do have, what we don't support fully
> > includes:
> >
> > - Merging
> ...
> > - Block/Unblock Changeset
>
> Not that I have much time right now to invest in this, but this lack
> of block is going to make merge tracking very very annoying - probably
> so much that I wouldn't even use merge tracking.
>
> Perhaps the easy way out is to just have 'svn block -c xxxx' do a
> record-only merge?
 
That's not a bad idea, actually. We provide a formalized command, document
the fact that you should record which values from svn:mergeinfo are blocked
for auditing and later migration, and fix the command in a subsequent
release. Given the amount of call we've had for this function, I can see
delivering *something* now as valuable even if the implementation is somewhat
questionable.

> But, if a rev constantly appears in the avail list, that's gonna be
> downright annoying - probably so much so that I'd stick with
> svnmerge.py. The galling point is that I don't think I'm the only one
> who uses block or expects it to be there.
 
Justin, you are most definitely not alone here. I get constant requests
for this feature.

The main reason for its deferral is the existence of the work-around of
using 'svn merge --record-only' with a separate "blocked" list; if these
other buggy or to-be-implemented features had work-arounds, I'd definitely
see this as prioritized higher.

If we were going to implement it like the suggested work-around, adding a
svn:blocked-mergeinfo property which contained references to values also
present in the svn:mergeinfo property pretty simple at face value, but when
you factor in elision, and the need to synchronized adjustment of both
property values, will take longer than one might expect to implement.

> (I frankly care more about block than I do about bi-directional
> merges.) -- justin

-- 
Daniel Rall