[Please CC followups to the mailing list. I am sending a CC of this
reply to users_at_subversion.tigris.org and in this case a Reply-To to the
dev_at_cvs2svn.tigris.org mailing list because it is more of a cvs2svn topic.]
Baeriswyl Kuno - Extern (IT-BA-MV) wrote:
> it seems that we proofed that great ideas pop up, if you put heads
> together. It's a excelllent idea. I already tried andrews advice. It
> seams to be working well. Though, I get a few warning about already
> existing branches. But I think I could ignore them.
>
> Now the problem is, that I can't migrate in parallel processes and after
> my first estimation, it would take more than one week to load the whole
> repository. Therefore, I must find a way to shrink the repository
> before. Meaning that we must cut some, but not all, history information.
> Do you have any idea how to do this? I'm thinking about creating a new
> Repository with the state of, let's say, Revision 10099. And then load
> the following revisions from a filtered dump file. I havn't tested this
> operation yet.
The easiest thing to do is exclude from the cvs2svn conversion branches
and tags that you don't need anymore. Often repositories have lots of
old stuff (e.g., nightly build tags) that are not worth preserving.
Second, get the fastest computer and especially the fastest hard disks
that you can find. In the extreme case, if you can run the conversion
on a ramdisk, you can save an order of magnitude of time.
Consider running cvs2svn and "svnadmin load" on two different computers.
The dump stream content could be piped through a network socket or via
ssh or something like that. This is currently not implemented, but it
wouldn't be too much work to add.
It might also be possible to add parallelism to cvs2svn (processing
multiple projects at the same time), but this would be more work.
Finally, consider whether you really want all of your projects in a
single SVN repository. If you keep them separate, then you can convert
one project after another and the individual projects' downtimes will be
much less.
I don't know of a good way to omit all history before a particular date:
- cvs2svn doesn't have such a feature. It might be doable, though there
would be some tricky cases such as what to do with a branch that was
forked from trunk before the cutoff date, but also has commits after the
cutoff date. It could be implemented in cvs2svn, but would require a
certain amount of work.
- To some extent you could delete ("obsolete") revisions from the CVS
repository before the conversion, but I don't think that CVS allows you
to obsolete any revisions that are the sources of branches or included
in tags.
- I'm not sure whether there is an SVN stream dump filtering tool that
is capable of excluding all commits before a particular date. But in
any case, this wouldn't speed up the cvs2svn part of the conversion,
only the "svnadmin load" part.
The problem with the suggested cvs2svn enhancements is that I am pretty
much the only cvs2svn maintainer, and I have very little time to work on
it. If you want to work on cvs2svn yourself I'd be happy to help you
get started. Or you might think of sponsoring some work on cvs2svn to
get the features you want implemented.
The final choice is to pick a long weekend or vacation time and run your
conversion then, to minimize the effect of the VCS downtime on your
developers.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-12 14:52:24 CEST