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

Re: cvs2svn patch in the works...

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-10-24 13:08:49 CEST

On Thu, Oct 24, 2002 at 12:05:40AM -0400, Daniel Berlin wrote:
> > object? If so, then you could just as well do:
> >
> > def get_key(f, r):
> > return intern(f + '--' + r)
> >
> > which works all the way back to Python 1.5.
> >
> > However, both approaches will not scale properly. It seems that you'll be
> > creating keys for practically every file *and* revision that is found in the
> > conversion process. That isn't going to work :-)
>
> Maybe if we create a BDB database of all the revisions and files.
> Oh, wait.
> :)

*ROFL*

> I repeat that anyone doing serious work on cvs2svn, should grab copies
> (through rsync) of the gdb and gcc CVS repos.

Can you point us at a page that describes the rsync set up? I'd like to do
do this, but I'm not sure how. (I generally know rsync, but what server,
what path, etc)

> gcc is a large repository with tons of branches (and branches created on
> branches), etc, tons of revisions, and tons of files.
> It should convert in a reasonable amount of time, unless your algorithms
> don't scale.
> (IE if you've got an O(n^2) algorithm somewhere, it'll likely take days to
> convert).

Right.

In the past, the SourceForge folks also offered their repository. I also
have the ASF repository, and some really huge ones at CollabNet and its
hosted customers. But the simplest is to use some open, rsync'able
repositories.

The ideal test is to build an svn2cvs program. You could then test by doing
cvs -> svn -> cvs and comparing the result against the original. Or even
adding one more -> svn in there and comparing the svn repo's.

Oh. The talk above about branches and whatnot also reminded me about
something. Earlier, I had mentioned a .conf file for fine-tuning the
conversion process. One of the other purposes for that file is to deal with
telling the process about how/where to look for copies. Ideally, cvs2svn
could see an add/remove in a commit and determine it was a move. But copies
are a bit tougher. But the case that I'm thinking of is the conversion of
the Apache web server. At some point, Apache 2.0 was forked out of the 1.3
development tree. If cvs2svn could build an aggregate repository of the 1.3
and 2.0 repositories, and also have an 'svn cp' for the point where 2.0 was
copied... hoo that would rock. You could trace 2.0 files all the way back in
time.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 24 13:08:56 2002

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

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