David Glasser wrote:
> On Feb 11, 2008 10:51 AM, <hwright_at_tigris.org> wrote:
>> Author: hwright
>> Date: Mon Feb 11 10:51:25 2008
>> New Revision: 29269
>>
>> Log:
>> First part of 'log -g' rework. This fixes log tests 17 and 19.
>
> Hyrum, I assume you can be on top of nominating your 'log -g' fixes to
> 1.5 when you're done?
Yeah, I've been keeping track of the pertinent revs.
>> This commit changes the structure of 'log -g' to be less streamy than it
>> previously was, with the benefit of cleaner output, and a more straightforward
>> algorithm. This creates a more clear separation between the 'log -g' and
>> vanilla 'log' functionalities.
>
> I'd be somewhat curious in hearing a little more explanation of this
> change, but I don't want to get in the way of you actually fixing it.
The "old" way of doing 'log -g' was to look for each revision, determine
if it was a merging revision, and then send it, and possibly its
children, to the client before moving to the next one. The problem I
was running into was when to stop following the children. Because trunk
and the branch both share the same history, eventually these histories
would converge, and we'd be sending back the same revisions multiple times.
This "new" method is similar, though it first traces back through the
history of the object, and then uses that list of history to prune the
children trees of merging revisions. When a merged line of history
converges with the original line of history, we stop following the
merged line.
In the "new" method, we still send log messages as we find them, and we
still traverse merged trees as we find them, so we are still streamy in
that regard. The difference is the upfront cost of discovering the
original line of history, so that we can remove duplicates early.
The performance is no worse than doing a "reverse" log, and I think that
it is an acceptable trade off for eliminating large amounts of duplicate
data. If this method stands, we should document that 'log -g'
turnarounds could be long, though no longer than 'blame'.
Does this help?
-Hyrum
Received on 2008-02-12 19:56:29 CET