[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Possible bug in cvs2svn.py

From: Jeff Squyres <jsquyres_at_lam-mpi.org>
Date: 2004-02-20 05:58:09 CET

First of all, thanks for all the great work on subversion! Now that 1.0
is immanent, we've playing with SVN and preparing to convert away from
CVS.

In light of that, I tried converting one of larger CVS repositories (with
commits dating back to 1990) earlier tonight. Near the end of the
analysis stage, cvs2asc.py starts displaying arbitrarly large CVS commit
times. This starts with a commit on 10 Jan of this year; all commits that
cvs2svn.py finds after this are marked with an absurdly large commit time.
Here's the point in the output where it starts reporting this large commit
time:

----
committing: Fri Jan  9 13:06:19 2004, over 0 seconds
    adding or changing 6.320 : trunk/HISTORY
    new revision: 9199
committing: Fri Jan  9 13:30:47 2004, over 0 seconds
    adding or changing 6.47.2.34 : branches/branch-7-0/VERSION
    new revision: 9200
committing: Sat Jan 10 08:37:04 2004, over 140450 seconds
WARNING: commit spans more than 300 seconds
    adding or changing 6.34 : trunk/share/boot/asc_parse.c
    new revision: 9201
committing: Sat Jan 10 08:37:04 2004, over 140502 seconds
WARNING: commit spans more than 300 seconds
    adding or changing 6.32.2.2 : branches/branch-7-0/share/boot/asc_parse.c
    new revision: 9202
-----
140450 seconds is about a day and a half.  I'm quite certain that the CVS
commit did not that that long.  For every commit that cvs2svn.py found
after that, the commit time increased.  More specifically, cvs2svn.py's
reported timestamp never changed after that commit (Sat Jan 10 08:37:04
2004) -- I'm guessing that these arbitrarily large commit times are the
actual commit completion time minus some previous, fixed time.  Hence, I'm
further guessing that some internal counter in the cvs2svn.py script
somehow didn't get reset for the last 80 or so revisions, and their
timestamps were therefore recorded incorrectly in the dump file.
It's still committing the dump file as I type this (and will likely
continue to do so for a while -- cvs2svn.py got up to r9283), but I'm
guessing/assuming that the timestamps in the SVN repository for all those
commits will be incorrect.
Anyone have any clues as to why this would happen?  I can provide more
details if necessary.
Many thanks.
(pardon any text that doesn't make sense; it's late! :-)
-- 
{+} Jeff Squyres
{+} jsquyres@lam-mpi.org
{+} http://www.lam-mpi.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 20 05:58:43 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.