[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Harald Meland
Subject: Re: [Gnu-arch-users] cscvs log parsing failure
Date: Mon, 29 Sep 2003 02:02:10 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v)

[Florian Weimer]

> On Mon, Sep 29, 2003 at 12:01:34AM +0200, Harald Meland wrote:
>> ... or bite the bullet and accept that we have to edit the output of
>> "cvs -q log" before passing it to "cscvs cache -f
>> /name/of/fixed/log/file".
> This could be the only solution that works.

Hmmm, I just had an idea: CVS states the total number of revisions
before it starts listing commit messages for each of them.  This means
that the CVS parser could count the number of revision separator lines
and compare with the given total number of revisions.

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

and *not* split the output more than once (to separate the header from
the commit message).

The list of revisions to iterate over can be built by retrieving the
revision number from all lines in the full output of "cvs -q log
%(filename)s" that

  1) follow immediately after a revision separator and
  2) match '^revision\s+(\d+(?:\.\d+)+)$'.

As the commit message is free text, this approach could give us some
dud revisions.  However, these will be readily recognizable; there
will be no line in the output starting with the string 'revision '.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]