Date: Tue, 25 Jan 2005 17:42:03 +0100
From: Andrea Arcangeli <andrea@suse.de>
To: CVSps@dm.cobite.com, Larry McVoy <lm@bitmover.com>
Cc: linux-kernel@vger.kernel.org, Andreas Gruenbacher <agruen@suse.de>
Subject: kernel CVS troubles with cvsps
Message-ID: <20050125164203.GY7587@dualathlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3120
Lines: 89

Hello,

sorry to annoy you about this, but something is going wrong with either
cvsps or the kernel CVS.

I reproducibly get this as the last changeset, note the date. The
--bkcvs breaks completely too, but that would be a minor issue since
cvsps by default will get it right from the dates that are atomic with
the bk2cvs conversion.

---------------------
PatchSet 58582
Date: 1970/01/01 01:33:25
Author: zwane
Log:
x86_64: Notify user of MCE events.

(Logical change 1.25778)

Members:
        arch/x86_64/kernel/mce.c:1.18->1.19


But cvs log says this:

[..]
description:
BitKeeper to RCS/CVS export
----------------------------
revision 1.20
date: 2005-01-15 23:24:52 +0000;  author: suresh.b.siddha;  state: Exp;
lines: +2 -2
x86_64: use cpumask_t instead of unsigned long

(Logical change 1.25965)
----------------------------
revision 1.19
date: 2005-01-12 01:51:57 +0000;  author: zwane;  state: Exp;  lines:
+18 -0
x86_64: Notify user of MCE events.

(Logical change 1.25778)
[..]

So something is going wrong, that's not even the last checkin in the
mce.c file, so it can't be the last global changeset. I thought it was
the kernel CVS being wrong since no change has happened to cvsps for a
long time, but now I'm not sure anymore because I couldn't find obvious
screwups in the kernel CVS yet. I reproduced with latest stable and
unstable cvsps. Kernel cvs is fetched with:

rsync -za --delete --force \
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.5/ linux-2.5/

Can somebody else reproduce it? It would be helpful to know somebody
else can reproduce it too.

Notably `cvsps -x` spawns a number of warnings while it builds the cache
which again made me think this isn't a cvsps mistake.

I get the same screwup in the 2.4 kernel CVS too (not only in 2.5/2.6):

andrea@dualathlon:~/devel/kernel/linux-2.4> cvsps -x
WARNING: non-increasing dates in encountered patchset members
WARNING: non-increasing dates in encountered patchset members
WARNING: non-increasing dates in encountered patchset members
WARNING: non-increasing dates in encountered patchset members
WARNING: non-increasing dates in encountered patchset members
WARNING: non-increasing dates in encountered patchset members
WARNING: non-increasing dates in encountered patchset members
WARNING: non-increasing dates in encountered patchset members


So I doubt it's some internal overflow of cvsps, plus it didn't start
happening on a special date (i.e. it happened in 2004 too).

Any help is appreciated. I'm just starting to look more seriously into
this since I've some tools that depends on the cvsps to work and kernel
CVS is the only fully coherent linearized source of info in open format
(rest is either a priorietary format or unusable because out of
synchrony because not linearized).  Until now I hoped that by waiting it
would automatically fixup, but it didn't yet ;).

Thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/