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
Received on Fri Nov 16 04:24:11 2007