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!
On Tue, Jan 25, 2005 at 05:42:03PM +0100, Andrea Arcangeli wrote:
> 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 ;).
FYI, I haven't tried using cvsps on the kernel CVS, but I used to use it on
GCC - and it fell down like this on a constant basis.
You might want to take a look at 'xcvs', by Jun Sun. It's much more
reliable and does everything I used to use cvsps for. And generally
faster too.
--
Daniel Jacobowitz
On Tue, Jan 25, 2005 at 11:58:07AM -0500, Daniel Jacobowitz wrote:
> FYI, I haven't tried using cvsps on the kernel CVS, but I used to use it on
> GCC - and it fell down like this on a constant basis.
Interesting, for me it always worked fine on the kernel until last
month.
> You might want to take a look at 'xcvs', by Jun Sun. It's much more
> reliable and does everything I used to use cvsps for. And generally
> faster too.
I'll check it, thanks for the info.
Andrea Arcangeli <[email protected]> writes:
> 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.
I noticed this problem some time ago when trying to see whether the
darcs repository is consistent with the BK one:
http://marc.theaimsgroup.com/?l=linux-kernel&m=110026570201544&w=2
A solution is to use the "(Logical change ...)" string within each
file's commit log instead of the date (I realised that it is simpler
to write a shell script to generate the diffs rather than modifying
cvsps).
Catalin
On Tue, Jan 25, 2005 at 05:10:17PM +0000, Catalin Marinas wrote:
> I noticed this problem some time ago when trying to see whether the
> darcs repository is consistent with the BK one:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=110026570201544&w=2
>
> A solution is to use the "(Logical change ...)" string within each
> file's commit log instead of the date (I realised that it is simpler
> to write a shell script to generate the diffs rather than modifying
> cvsps).
Thanks for the confirmation. To me this hour difference looks like a bug
in bkcvs. It would be nice to get it fixed so we don't have to
workaround it in cvsps or hack around more scripts.
Thanks.
We're a little busy right now, we'll try and get to this.
On Tue, Jan 25, 2005 at 08:09:58PM +0100, Andrea Arcangeli wrote:
> On Tue, Jan 25, 2005 at 05:10:17PM +0000, Catalin Marinas wrote:
> > I noticed this problem some time ago when trying to see whether the
> > darcs repository is consistent with the BK one:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=110026570201544&w=2
> >
> > A solution is to use the "(Logical change ...)" string within each
> > file's commit log instead of the date (I realised that it is simpler
> > to write a shell script to generate the diffs rather than modifying
> > cvsps).
>
> Thanks for the confirmation. To me this hour difference looks like a bug
> in bkcvs. It would be nice to get it fixed so we don't have to
> workaround it in cvsps or hack around more scripts.
>
> Thanks.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com