[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: |
Sun, 28 Sep 2003 16:03:39 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v) |
[Florian Weimer]
> There's the following code in the CVS log parser:
>
> | elif log_list and log_list[-1] == '':
> | # We have a revision separator line followed by a
> | # new revision indicator, but the separator was
> | # preceded by an empty line.
> | pass
>
> What's the reason behind this?
That's my bad, I'm afraid. When trying to import the Mailman CVS, I
came across the following revision:
----------------------------
revision 2.107
date: 2002/11/04 21:35:05; author: bwarsaw; state: Exp; lines: +1 -1
GLOBAL_PIPELINE: Re-ordering once again so that Moderate comes before
Hold. Chuq says:
looks like 2.1b4 is evaluating messages slightly out of order. If
I get a large piece of spam (my message limit is 30K, the spam is,
say, 60k), it gets held as too large, before the evaluation can
take place that should reject it as being from a
non-subscriber. Seems to me these evaluations ought to be
reversed...
But I must have had a good reason for changing this in rev 2.102:
----------------------------
revision 2.102
date: 2002/08/23 19:56:08; author: bwarsaw; state: Exp; lines: +1 -1
GLOBAL_PIPELINE: Reordering the modules so that Hold comes before
Moderate.
----------------------------
Unfortunately, the checkin message doesn't give me a clue as to why I
made this change. I'm sure the reason will become evident soon
enough. :(
----------------------------
revision 2.106
[...]
As I could find no other instances of ('\n\n' + revision-separator), I
assumed it was safe to work around this "cvs log output included in
commit message" trouble by the above hack.
> The Mutt CVS contains these revisions:
> | ----------------------------
> | revision 1.1.1.1
> | date: 1998/06/08 09:16:03; author: roessler; state: Exp; lines: +0 -0
> |
> | ----------------------------
> | revision 1.4.2.5
> | date: 1998/07/14 16:01:02; author: roessler; state: Exp; lines: +46 -0
> | branches: 1.4.2.5.2;
> | Preparing mutt 0.93.1i.
> | ----------------------------
This proves my assumption false, I'm afraid, which means my attempted
fix is wrong. However, I'm at a loss as to what a proper fix would
be. :-(
As a potentially useful data point, what cvs version are you using
(both client- and server-side, if applicable)?
--
Harald
- [Gnu-arch-users] cscvs log parsing failure, Florian Weimer, 2003/09/28
- Re: [Gnu-arch-users] cscvs log parsing failure,
Harald Meland <=
- Re: [Gnu-arch-users] cscvs log parsing failure, Florian Weimer, 2003/09/28
- Re: [Gnu-arch-users] cscvs log parsing failure, Harald Meland, 2003/09/28
- Re: [Gnu-arch-users] cscvs log parsing failure, Florian Weimer, 2003/09/28
- Re: [Gnu-arch-users] cscvs log parsing failure, Harald Meland, 2003/09/28
- Re: [Gnu-arch-users] cscvs log parsing failure, Florian Weimer, 2003/09/29
- Re: [Gnu-arch-users] cscvs log parsing failure, Harald Meland, 2003/09/29
- Re: [Gnu-arch-users] cscvs log parsing failure, Florian Weimer, 2003/09/29
Re: [Gnu-arch-users] cscvs log parsing failure, Charles Duffy, 2003/09/28