[Monotone-devel] Re: newbie: Life after cvs-import

[Bruce Stephens]

"Kelly F. Hickel" <address@hidden> writes:

[...]

> 2) How can we be reasonably certain that mtn imported useful things
> from cvs? My coworker is of the opinion that since importing
> everything leads to a big database (1gb), and we can't be sure it
> imported "everything correctly" that we're better off junking all
> the history, that way nothing will bite us in the end.

Well, quite: how do you test?

At work we're considering the same question (and have been for a few
years now).  We've got a largish (1.9G), old, complex CVS repository,
at least some of which we need to keep around (we have customers still
using releases from a few years ago, and we need to be able to support
them).

But everyone can see that something other than CVS might offer some
benefits (tracking renames of files, for one thing).  The question's
whether changing is worth the inevitable pain.

Obviously the front-runner is subversion (it's the least-frightening
option, <http://keithp.com/blog/Tyrannical_SCM_selection.html>): lots
of people use it, it'll work well on Windows, and it's got a decent
chance of importing our repository bug-compatibly with the CVS one.

But cvs2svn produces warnings, saying that some versions already have
a branch symbol, so it's dropping the later one.  (Dropping the
earlier one would seem likely to be better, but never mind.)  That
kind of thing.

I'm reasonably confident that the resulting repository contains all
that we're likely to care about, but how can we be sure?


Anyway, I'm with your coworker: make a switch, keeping the CVS
repository for history, and switch to something else for the future,
importing whatever of the history seems practical and useful.  Apart
from anything else, that should give you more options: you can
rearrange the way you store things, you don't need to pick subversion
(because subversion is the only thing capable of importing CVS well
enough), etc.

[...]