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

[Bruce Stephens]

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

[...]

> [Kelly F. Hickel] One of the problems that I have with this, is
> *when* do you switch?  There's no point in time where we don't have
> active branches, so that means that most developers will be working
> in both cvs and mtn, which I see as prone to errors.  Nevermind that
> it's more work to deal getting updates into mboth systems, being
> reasonably sure they're right in both, full testing and so on, and
> so on....

Yes, that's certainly an issue.  I think there wouldn't be much of an
overlap (for us, anyway), since we do most development on the trunk.
So all (existing) branches would stay in CVS, and we'd do new
development in mtn (or subversion, or whatever).  And that wouldn't be
*too* disruptive, although certainly most of us would be regularly
making changes in both systems for at least a few months.

And also our process mostly involves using scripts which (for example)
commit changes to multiple files in one operation.  So our direct
dependence on CVS isn't *that* great (although we certainly use CVS
directly sometimes).

But yeah, it's not ideal.  It would be nicer to migrate everything to
a new system, and then we'd just need to learn and use that one
system.

I'm just not convinced we're ever going to find a system capable of
replicating our repository, or be sufficiently sure that it's imported
everything that we care about.

And if we did, I'd be a bit worried: part of the reason for wanting to
move is (IMHO) that CVS's file-based model is suboptimal.  Anything
capable of representing that precisely probably has something wrong
with it.

I tried git's cvsimport a week or two ago, and I'm impressed.  It
screwed up the vendor branches, but the main part of the repository
looked fairly plausible.  And surprisingly small, and astonishingly
fast.  But again, how can I test that, to gain confidence that it
would be accurate enough to replace our CVS repository?  (And I guess
git's not really an option unless it works well enough for Windows.)

I haven't yet tried mtn's cvs features, though I will.  (Because of
our use of these scripts, whenever I do this I need to make changes to
accommodate our use of CVS: in our changesets we have changes with
distinct changelogs.)