You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jeff Squyres <js...@lam-mpi.org> on 2004/02/20 04:58:09 UTC
Possible bug in cvs2svn.py
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
Re: non-existent revision after dump + svndumpfilter
Posted by Gerald Richter <ri...@ecos.de>.
>
> Here's a different question: If you run without --drop-empty-revs,
> and then do:
>
> $ grep 'Revision-number: ' orig-dumpfile | wc -l
> $ grep 'Revision-number: ' filtered-dumpfile | wc -l
>
> Do you get matching values for the number of revisions in each
> dumpfile?
Yes, but I have another idea. I done the svnadmin dump starting with a
revision number, so I only get the revisions above (and thats the number
your above commands show).
So I retry the dump, this time without revision number. After running
svndumpfilter I get an error during svnadmin load at the revision where the
directory I like to split out was copied from another directory, saying
"File not found". So it seems like I cannot split out a directory, without
the directory which holds the copy history. Is this true?
Thanks
Gerald
--------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 939-122
WWW: http://www.ecos.de/ Fax: +49 6133 939-333
--------------------------------------------------------------
|
| ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: non-existent revision after dump + svndumpfilter
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Gerald Richter" <ri...@ecos.de> writes:
> Hi,
>
> thanks for the feedback
> >
> > Did you run svndumpfilter with the --drop-empty-revs option? If you
> > want to preserve those working copies, *don't do that*. If you drop
> > empty revisions, there's no way you'll get all those working copies
> > synchronized again.
>
> If have tried with and without --drop-empty-revs . In both cases the
> resulting repsitory which I get after the svnadmin load has viewer revisions
> then the original one and svn up fails, because the working copy is at an to
> high revision number.
Hmm... that's inconsistent with my understanding (and testing) of how
svndumpfilter works.
Here's a different question: If you run without --drop-empty-revs,
and then do:
$ grep 'Revision-number: ' orig-dumpfile | wc -l
$ grep 'Revision-number: ' filtered-dumpfile | wc -l
Do you get matching values for the number of revisions in each
dumpfile?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: non-existent revision after dump + svndumpfilter
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Gerald Richter" <ri...@ecos.de> writes:
> Hi,
>
> we have a large svn repository we need to split into mutiple, so I run a
> svnadmin dump and svmdumpfilter to split out the needed subtree and loaded
> it into a new svn repository. This works fine and I get exact the desired
> result.
>
> My problem is there are a lot of exiting working copis and I want to be able
> to switch them without haveing to do a new checkout (because actually
> nothing changed and if all users do a new checkout this would cause a lot of
> network traffic over a slow link). So I tried svn switch --relocate which
> works, but doing a svn up afterwards gives me a "Reference to non-existent
> revision XXX' in the Apache error log.
>
> Of course this revision does not exist, because of the svndumpfilter, the
> new respository has fewer revision then the old one.
Did you run svndumpfilter with the --drop-empty-revs option? If you
want to preserve those working copies, *don't do that*. If you drop
empty revisions, there's no way you'll get all those working copies
synchronized again.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
non-existent revision after dump + svndumpfilter
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
we have a large svn repository we need to split into mutiple, so I run a
svnadmin dump and svmdumpfilter to split out the needed subtree and loaded
it into a new svn repository. This works fine and I get exact the desired
result.
My problem is there are a lot of exiting working copis and I want to be able
to switch them without haveing to do a new checkout (because actually
nothing changed and if all users do a new checkout this would cause a lot of
network traffic over a slow link). So I tried svn switch --relocate which
works, but doing a svn up afterwards gives me a "Reference to non-existent
revision XXX' in the Apache error log.
Of course this revision does not exist, because of the svndumpfilter, the
new respository has fewer revision then the old one. Is there any way around
this problem. Something to tell svn to bring the revisions of the repository
and the working copy in sync?
Thanks
Gerald
--------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 939-122
WWW: http://www.ecos.de/ Fax: +49 6133 939-333
--------------------------------------------------------------
|
| ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Possible bug in cvs2svn.py
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Fri, 20 Feb 2004 kfogel@collab.net wrote:
> > What are these unlabeled branches?
>
> Ah, thank you for asking -- now I know something I need to document.
>
> Those are for branches that don't have labels (symbolic names). This is
> quite possible in an RCS file. Look in the revision header section of
> some of those RCS files, you'll see branch commits, yet the symbolic
> names section will have no label for that branch.
Indeed, you're right -- thanks for replying.
I wonder how those got there... time to go start knocking some skulls...
;-)
--
{+} 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
Re: Possible bug in cvs2svn.py
Posted by kf...@collab.net.
Jeff Squyres <js...@lam-mpi.org> writes:
> So I went and got the most recent subversion (r8786), and ran that
> cvs2svn.py on my large CVS repository. The large commit time problem went
> away.
>
> But here's a new wrinkle -- it created a bunch of small directories named
> "unlabeled-x.y.z" in the branches/ subdirectory in the new SVN repository.
>
> I had a look at some of the files in there, and they're typically very
> small sets of files (i.e., it looks like one changeset), but there's no
> obvious branch tag in the original CVS repository for that commit.
>
> What are these unlabeled branches?
Ah, thank you for asking -- now I know something I need to document.
Those are for branches that don't have labels (symbolic names). This
is quite possible in an RCS file. Look in the revision header section
of some of those RCS files, you'll see branch commits, yet the
symbolic names section will have no label for that branch.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Possible bug in cvs2svn.py
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Fri, 20 Feb 2004, Jeff Squyres wrote:
> > ... which was recently resolved. Are you using the very latest cvs2svn?
>
> Doh! Yes, this looks like exactly my problem.
So I went and got the most recent subversion (r8786), and ran that
cvs2svn.py on my large CVS repository. The large commit time problem went
away.
But here's a new wrinkle -- it created a bunch of small directories named
"unlabeled-x.y.z" in the branches/ subdirectory in the new SVN repository.
I had a look at some of the files in there, and they're typically very
small sets of files (i.e., it looks like one changeset), but there's no
obvious branch tag in the original CVS repository for that commit.
What are these unlabeled branches?
--
{+} 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
Re: Possible bug in cvs2svn.py
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Thu, 19 Feb 2004 kfogel@collab.net wrote:
> > Anyone have any clues as to why this would happen? I can provide more
> > details if necessary.
>
> This sounds a lot like
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1744
>
> ... which was recently resolved. Are you using the very latest cvs2svn?
Doh! Yes, this looks like exactly my problem.
My mistake -- I looked through the unresolved issued before posting; I
didn't use the search functionality to check resolved issues.
Thanks!
--
{+} 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
Re: Possible bug in cvs2svn.py
Posted by kf...@collab.net.
Jeff Squyres <js...@lam-mpi.org> writes:
> 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.
This sounds a lot like
http://subversion.tigris.org/issues/show_bug.cgi?id=1744
... which was recently resolved. Are you using the very latest cvs2svn?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org