Re: Reconstructing thoughts about implicit mergeinfo

Mark Phippard wrote:
> You have to take everything I say with a grain of salt because since I
> do not work down in the code I could use terms different than Dan,
> Paul etc do. That being said, I view there are two kinds of
> mergeinfo:
>
> implicit - this is created at the time a path is created. It is the
> history of revisions and paths that initially make up the item.
>
> explicit - everything that is merged into the path after it is created.

Yes, I understand your definitions. I don't understand why those are the
definitions chosen.

My understanding of the whole point of merge tracking is that we're trying
to keep track of all the sources of changes made to a given directory that
*are external to* the regular ol' update-edit-commit cycle. Copies are
*not* external to that cycle. A copy doesn't feed data from some other
source into an existing object -- quite the opposite. So I don't understand
why 'svn copy trunk branches/my-branch' should record mergeinfo on
branches/my-branch. The information there is completely redundant with the
information already contained in branches/my-branch's history. It doesn't
represent changes brought into my-branch from some other source, because
that source is just my-branch itself prior to some name change (which I
posit is irrelevant from the standpoint of history tracking).

> Perhaps I need to see your definitions.

I provided them in my original mail:

   Every node's ancestry set consists to two things:

      1. its natural version history (changes made and committed
          directly to the object or its children), and
      2. merges of changes made to alternate lines of history.

   The first of these we call "implicit mergeinfo"; the latter "explicit
   mergeinfo". Explicit mergeinfo can be stored literally on a node via
   the svn:mergeinfo property, or can be inherited from its parent
   directory.

>> This logic concerns me, and relates to a question I asked Paul yesterday
>> about svn:mergeinfo on a path having references to merge sources from the
>> same path. Say I have a single branch (trunk) that I'm working on, and need
>> to undo a committed change. I merge -c-N the change. Now, do we expect
>> that the mergeinfo for trunk contains:
>>
>> /trunk:-N
>>
>> ? I say "no". Why do I rate a special record of an undoing commit, when I
>> don't have any special records of "doing" commits?
>
> I say "no" too. If a path is created by copying trunk at r100 you get
> this mergeinfo:
>
> /trunk:1-100
>
> If you do a reverse merge of revision 90, the mergeinfo should be
> changed to this:
>
> /trunk:1-89,91-100

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.

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

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. 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

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

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.

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.

I'm terribly sorry if I'm overthinking (or worse, underthinking) this
problem. 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.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand