> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Tuesday, November 06, 2007 10:14 AM
> To: Mark Phippard
> Cc: Daniel Rall; Subversion Developers
> Subject: Re: Reconstructing thoughts about implicit mergeinfo
<snip>
> You changed the scenario. I didn't say anything about a
> copy. I'm talking about simply using merge to undo a
> revision previously made on a given line of history. Should
> we record that fact or not?
>
> But let's look at your example, incorporating mine into to.
> We have a trunk, and we have a branch 'foo' created from
> trunk@100. In r90 of the trunk, someone committed a nasty
> bug. In r110, they reverse-merged r90 and committed,
> effectively undoing the bug introduction.
Hi Mike,
I'd like to mirror your example here, but use the definition of implicit
mergeinfo that exists on trunk today. Though I'm sure you have already
done this it might be useful for others reading this (and maybe
something enlightening will fall out of this).
> So, first things first. When the reverse-merge of r90 was
> committed to trunk as r110, did it introduce mergeinfo *on
> trunk itself* of:
>
> /trunk:-90
While r27519 http://subversion.tigris.org/issues/show_bug.cgi?id=2973
purposely special cased reverse mergeing where source and target are the
same, i.e. it allows this
$ svn merge -c-90 http://.../trunk trunk
to work, it *doesn't* change trunk's mergeinfo because we currently
don't support negated revision ranges -- FWIW a concept which has other
applications: http://subversion.tigris.org/issues/show_bug.cgi?id=2881.
> The answer to this question is critical to my understanding
> of what we're trying to do here; hand-waving around this is
> not an option for me.
>
> Moving on, using my definition of implicit mergeinfo (which
> is a misnomer, really, as it has nothing to do with merging),
> when I created the branch 'foo' from trunk@100, there was no
> need to record any mergeinfo whatsoever yet.
Ok, today (r27617) when we create 'foo' from trunk@100 'foo' gets
implicit mergeinfo from trunk of:
'/trunk:1-100' (assuming for now that 'trunk' was created in r1)
So 'foo' earns some mergeinfo as soon as it is copied. And once the
copy is done, 'foo' has mergeinfo, there is no real concept of it having
special 'implicit' mergeinfo.
> I had not yet
> introduced changes to 'foo' from an alternate line of
> history. I had merely forked a single line of history.
>
> Now I wish to merge the bugfix from the trunk. There are a
> few ways to do this.
>
> First, I could merge the undoing revision committed in r110.
>
> $ svn merge -c 110 http://.../trunk trunk
>
> To me, this now earns 'foo' some mergeinfo:
>
> /trunk:110
Today foo gets r110 added to it's mergeinfo too, resulting in:
'/trunk:1-100,110'
> Why? Because this is the first time in the history of 'foo'
> that the source of our changes was some alternate line of
> history (the other tong of our fork from trunk).
>
> Alternatively, we could reverse-merge r90 onto 'foo' using
> trunk as the source, fixing the bug on our branch the same
> way it was fixed on the trunk.
>
> $ svn merge -c -90 http://.../trunk branches/foo
>
> But here's where I question what happens. Should 'foo' get
> mergeinfo now?
>
> /trunk:-90
On trunk today this sets foo's mergeinfo to:
'/trunk:1-89,91-100'
I hadn't previously appreciated that we can end up with the same net
effect on foo's contents but have two different ways of describing it in
foo's mergeinfo -- though I'm not sure if this is a problem.
> In my opinion, this is *exactly the same scenario* as when we
> reverse-merged r90 on trunk itself, and therefore should have
> exactly the same results.
Well it does have the same results in everything *except* the mergeinfo,
is this really a problem? To make it identical we'd have to implement
negeated revision ranges in svn:mergeinfo, and that gets back to one of
your other questions, "Why do I rate a special record of an undoing
commit, when I don't have any special records of 'doing' commits?"
> Finally, we could reverse-merge r90 using 'foo' as the source.
>
> $ svn merge -c -90 http://.../branches/foo branches/foo
>
> But my merge source normalization logic would internally
> remap this as a reverse-merge of r90 using trunk as the
> source, so this becomes the same as the previous method.
Today this operates exactly the same too.
> I'm terribly sorry if I'm overthinking (or worse,
> underthinking) this problem.
Probably neither, the implicit mergeinfo from copies has been in place
from early on. Speaking for myself I've been guilty of thinking "that's
just the way it works" and not seeing potential problems while wrestling
around in the mud of elision, non-inheritable ranges, etc.
Sorry if this just muddies the waters, trying to step back and think
about this some more too...
Paul
> And I know I'm trying to catch
> up on many, many moons of work done before I looked at the
> first line of merge tracking code. Hopefully someone can set
> me straight right quick and, as a result, educate the
> community as a whole.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 6 18:58:41 2007