Re: Reconstructing thoughts about implicit mergeinfo

On 11/5/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> [Cc:ing dev@subversion]
>
> dlr, markphip:
>
> As I started thinking about the implicit mergeinfo situation today (issue
> #2875), I realized a big hole in my proposal from last week. (And this
> might be exactly what you guys were trying to express on our phone call
> about the topic.) The problem is this: if we have a flag on some object's
> svn:mergeinfo property that says, "All my implicit mergeinfo is now
> explicitly recorded", that information is out of the date the minute we
> commit changes to that object. I mean, we've extended the history of the
> object, and the implicit mergeinfo is defined as "the natural version
> history of the object". That's no good.
>
> This caused me to try to reconstruct our thoughts from the call about this
> last week, but my memory being imperfect, I ultimately failed. I mean, I
> made some notes about specific scenarios we discussed, but they don't cover
> everything.
>
> So I started with a basic bit of definition stuffs, like so:
>
> 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.
>
> And then naturally I added the line, "These two sources of ancestry data
> should not overlap". This brought me back all the way to the ground zero on
> this problem.
>
> At this point, I'm strongly considering going with the naive approach:
>
> 1. always add implicit mergeinfo to the explicit when
> calculatin', and
> 2. always remove implicit mergeinfo from the results before
> storin'.
>
> The fear here is that asking the server for implicit mergeinfo will be
> costly. And that's a real issue, regardless of server pedigree. I realize
> now that had we a filesystem table that mapped node_id -> first_node_rev_id
> (basically, for any line of history, what was the first node revision in
> that line of history), we could *vastly* improve the speed of this operation
> to the ultimate benefit of all. But I dunno if adding such an index is
> within scope for 1.5 (it could just as easily be added later).
>
> If I don't take the naive approach, then I need to find a solution that
> works better than my "implicit-mergeinfo-is-explicitly-represented" flag,
> because I now see the folly of that.
>
> Thoughts? (And sorry if you guys saw this coming all along and I just
> missed it.)

I am not sure it is as bad as you think. The implicit mergeinfo for a
path should essentially represent the history of the item when it was
copied. If you copy /trunk @ r100 to make a branch then the implicit
mergeinfo for the branch is trunk from its creation to r100. Although
currently I believe you also get whatever is in the mergeinfo property
for trunk which would include information about other branches that
have been merged into trunk.

It sounded like you felt like you could ask the repository for this
information when needed rather than require it to live in the
mergeinfo property. That being said, we also agreed that at some
point this information does need to be stored in the property. It
seemed like we had a couple of ideas here:

1) Do it the first time the mergeinfo is needed. i guess this would
happen when you first merged into the location?

2) Do it the first time the implicit mergeinfo needs to be modified.
This would be a reverse merge that removed some of the revisions that
were originally copied into the path. This would require some kind of
special indicator in the property that told you whether this has
happened or not.

The key is that we have to support the scenario of #2. In theory the
implicit mergeinfo for an item could be changed. Dan's example was
good. Suppose you make a branch off trunk and start working on it.
Now, some big bug is discovered in trunk so a reverse merge is done on
trunk and all active branches to remove that commit. When this is
done, that implicit mergeinfo on the branch now needs to reflect that
the revision it inherited from trunk has been explicitly removed.

I am not sure this helps, but it is a dump of my relevant memory.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org