Re: 'log -g' and the removal of implicit mergeinfo

Mark Phippard wrote:
> On Nov 15, 2007 10:23 PM, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
>> Dan, Mike, Mark and I had a conference call this afternoon in which we
>> discussed how Mike's work on the mergeinfoless-copies branch could
>> affect 'log -g'. Among other things, the conclusion was that losing the
>> implicit mergeinfo on a copy would make eliminating redundant log
>> messages easier, because it wouldn't see the mergeinfo, and attempt to
>> trace to the source of the merge.
>>
>> As I've had more time to ponder the scenario, I'm still not quite
>> convinced. The reason we have to worry about redundant log messages
>> isn't because the mergeinfo exists, but rather because we are tracing
>> multiple lines of history which share history, and which will eventually
>> converge on a shared ancestor. Both lines of history will then produce
>> redundant log messages.
>>
>> The reason we were using the implicit mergeinfo was to help detect when
>> a branching copy, and thus avoid duplicating history. The heuristic was
>> basically a poor man's --stop-on-copy for branches. It wasn't perfect,
>> but worked good enough.
>>
>> If we remove implicit mergeinfo, we can't use this method. Is there a
>> better way? Or, have we been solving the wrong problem all along? How
>> can we capture only the changes on the branch, and not trace back to the
>> original history?
>
> My recollection of this is different. You wrote the code though, so I
> will obviously defer to you. The way I remember it, you run
>
> svn log -g somepath
>
> As it is doing the normal log processing, it encounters revisions
> where merges happened. My understanding was that it detected this
> because the revision altered the mergeinfo property. The problem was
> that when the normal log processing reached the revision where a
> branch was created, that revision also altered the mergeinfo.
> Therefore, before you added this heuristic, it would treat this
> revision as if it were a merge and would show all of the revisions
> that were copied.
>
> With the changes Mike is making the revision where a branch was
> created should look like a normal commit. There is no code you would
> reasonably write that would misinterpret that revision as a merge.
> Therefore, the problem we were dealing with should not exist.
>
> Ultimately it comes down to this. Your code needs to detect revisions
> where merges happened so that it can "explode" them and show the
> merges that happened. In our current code, a copy looks a lot like a
> merge. With Mike's changes, a copy will no longer look like a merge
> and therefore should not pose any special challenges to the algorithm.

You are right in saying that with mergeinfoless-copies, we wouldn't have
to worry about picking up the mergeinfo created by a copy. Currently,
we have to do a few tricks to remove this mergeinfo, and making this
change would simplify those tricks. However, a second problem arises,
doesn't relate to following mergeinfo, but to following history.

I guess I should use a concrete example. Consider the following:

- Mainline of development is /trunk (r1-r5)
- User creates a copy of /trunk in /branches/a (r6)
- User does work on /branches/a (r7-r12)
- User merges /branches/a back to /trunk (r13)

The command 'svn log -g /trunk' should yield the following log messages:
r13
r12 (via r13)
r11 (via r13)
r10 (via r13)
r9 (via r13)
r8 (via r13)
r7 (via r13)
r6 (via r13)
r5
r4
r3
r2
r1

But, if we don't stop at the branching copy, we get the following:
r13
r12 (via r13)
r11 (via r13)
r10 (via r13)
r9 (via r13)
r8 (via r13)
r7 (via r13)
r6 (via r13)
r5 (via r13)
r4 (via r13)
r3 (via r13)
r2 (via r13)
r1 (via r13)
r5
r4
r3
r2
r1

Note that r1-r5 are duplicated. *This does not happen as a result of
mergeinfo,* but rather, as a result of two objects sharing the same
history, and that history being followed through copies. /branches/a@6
is a child of /trunk@5, just as /trunk@6 is, so those histories would
converge on the same common ancestor.

What I am claiming, is that there is a second problem here, which
detecting implicit mergeinfo used to solve, partially. If we remove
implicit mergeinfo, we need to either be satisfied with duplicate log
messages, or determine another way to stop tracing history on a
branching copy.

(I see a possible solution to the problem, but it involves checking the
history of the source a priori and then determining matching potential
copy sources of the branch with those locations on trunk. This would be
a linear search, and probably make log prohibitively slow on large
datasets.)

-Hyrum