Re: [Gnu-arch-users] cscvs log parsing failure

[Harald Meland]

[Florian Weimer]

> On Mon, Sep 29, 2003 at 02:02:10AM +0200, Harald Meland wrote:
>
>> If the numbers match, all is well, we can go ahead and split naively
>> on the separator lines.
>> 
>> If the numbers don't match, the parser can fall back to doing
>> 
>>   for revision in revisions:
>>       cvs -q log -N -r%(revision)s %(filename)s
>
> This is extremely inefficient and usually kills inetd-based pservers.

Given the demonstrated lack of needed parsing hints in the output of
"cvs -q log", I suspect it is close to being as efficient as possible,
while still being correct.

Note, though, that this is only a fallback mechanism.  It only kicks
in for files where one or more commit message contains the revision
separator.  This means that parsing for most CVS modules would likely
be unaffected; for Mailman CVS, parsing the log of _one_ file
(Mailman/Defaults.py.in) will be slow.

As such an uncommon fallback mechanism, it could also be appropriate
to do a "sleep X" between getting each revision's log, in the hope
that the resulting reduction in connect frequency would be enough to
avoid killing e.g. inetd-based pservers.  X could be configurable
through a cscvs command line option.

>> > Unfortunately, there isn't a command to suppress the log messages,
>> > either.
>> 
>> I'm not following what you mean by that statement; the CVS log
>> messages are fairly central to cscvs' operation.
>
> The idea is to gather an authoritative list of revisions in the proper
> order.

... and group consecutive revisions by the same author into a single
changeset iff their log messages are the same.

Even if you *only* want to sort the revisions by commit time, and not
bother with grouping by author/log message, you'd still need to parse
the output of "cvs -q log" to discern 1) which revisions are present
for file F, and 2) what is the commit time for each of these
revisions.
-- 
Harald