Hyrum K. Wright wrote:
> 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)
Okay. So in my branch, no mergeinfo is created until r13. The mergeinfo
created for r13 is: "/branches/a: 6-13" Note that r1-r5 are *not* in this
mergeinfo. Why? Because the merge logic is smart enough to realize that
trunk already has r1-5, and therefore doesn't need to merge that portion
from /branches/a. (This is part of the merge source normalization code,
actually -- it should work this way in our trunk code today.)
> 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
Yeah, see above. I don't think we'll actually get the wrong thing here.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Nov 16 07:25:34 2007