You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2007/11/16 03:23:58 UTC
'log -g' and the removal of implicit mergeinfo
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?
-Hyrum
A related mail from June is here:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=127793
Re: 'log -g' and the removal of implicit mergeinfo
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright wrote:
> Mark Phippard wrote:
>> On Nov 15, 2007 10:23 PM, Hyrum K. Wright <hy...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 'log -g' and the removal of implicit mergeinfo
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> On Nov 15, 2007 10:23 PM, Hyrum K. Wright <hy...@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
Re: 'log -g' and the removal of implicit mergeinfo
Posted by Mark Phippard <ma...@gmail.com>.
On Nov 15, 2007 10:23 PM, Hyrum K. Wright <hy...@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.
--
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