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

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.

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