[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: reverse-merge broken?

From: Jack Repenning <jrepenning_at_collab.net>
Date: 2007-10-19 18:17:32 CEST

On Oct 19, 2007, at 3:05 AM, Mark Phippard wrote:

> On 10/18/07, Daniel L. Rall <dlr@finemaltcoding.com> wrote:
>> We absolutely have to perform the reverse merge, regardless of
>> mergeinfo
>> on the merge target.
>
> My initial instinct was the same, but thinking some more. Suppose you
> merge something. Then reverse merge part of it. Then later decide to
> reverse merge all of it. Would we want it to be able to use the
> mergeinfo here to understand the situation and not repeat parts of the
> reverse merge?
>
> Or would we just think it does not matter or is not worth it?

I think the "absolutely have to" thing is the simple case (indeed,
the one in my actual example):

1. merge branch to trunk
2. "merge -c-N" (also known as "woops")

More complicated stories are easy to weave, and there may be useful
things we can do by being clever with them, but the base story
doesn't go away, and "simple things easy, complex things possible"
says that the base case, and probably several not-much-more-complex
cases as well, "absolutely have to be doable."

I smell the possibility of complex stories we can detect but not
actually act upon, somewhere around here, and hope we'll consider
warnings to fill gaps, as well as those "do the right thing" cases we
can achieve.

In your example (partial reversal followed by full reversal), it
would certainly be best to "finish the reverse merge" rather than
"over-do the reverse merge." Not so good as that, but still better
than nothing, would be "over-do the reverse merge, but warn that
"file foo.rby may have been double-un-merged" (wow, Orwell lives!).
But even merely "over-doing the reverse merge" would be better than
"disabling the ability to do the simple un-merge." I could live with
any of those positions except the last (which, of course, is where we
are just now).

Some of those "not-much-more-complex cases that absolutely have to be
doable" might be:

Remote unmerge
1. merge branch to trunk
2. make unrelated changes in trunk
3. unmerge #1

Unmerge conflicts
1. merge branch to trunk
2. make (trunk) changes to lines delivered into trunk by #1
3. unmerge #1 produces a merge conflict over the lines mentioned in #2

-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 18:17:38 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.