Call for testing: cvs2bzr

[Ian Clatworthy]

Michael Haggerty wrote:

> On a quick overview, your patch looks reasonable.  The only difference I
> see from cvs2git is the use of inline blobs and, basically, s/git/bzr/.
>  Is that all that is needed to support cvs2bzr?  (If so, cool!)

That's pretty well it. We *could* handle a separate blobs file but it's
nicer w.r.t. memory consumption for us to go the inline blob path ala
hg. Unlike hg though, bzr has no limitations w.r.t. merge parent count.

> Let me know when you would like me to pull this patch.  I would have a
> pretty low acceptance threshold, since it doesn't involve much code and
> there currently is no cvs2bzr at all.

It's ready to go IMO. A Bazaar branch with my changes is available from
https://code.launchpad.net/~ian-clatworthy/+junk/cvs2svn. It should be
pretty easy to grab the diffs (mostly new files) from there. If not, let
me know how you'd like the patch put together.

> But there are a few other things
> that would be nice:
> 
> * A www/cvs2bzr.html page (or perhaps a shared www/cvs2fast-import.html
> web page).

Done.

> * A patch to contrib/verify-cvs2svn.py to allow it to verify cvs2bzr
> conversions.  Greg Ward has already abstracted out the parts that vary
> from VCS to VCS.  (Ultimately we should develop at least some minimal
> test suite for checking non-2svn conversions.)

Whatever works for hg, ought to work for bzr here. We also allow
multiple merge parents though. I'll add this to my list but no promises
as to when I'll get to it. My list is overly long right now. :-(

> * A cvs2bzr-example.options file.

Done.

> When Greg Ward is further along on cvs2hg [1], we should think about
> refactoring the common code a little better, maybe s/Git/FastImport/ and
> make git, bzr, and hg all peers that derive from the shared code.

That would be good. I've copied Greg on this email as my changes may
help him get cvs2hg in place sooner.

While it has limitations and can't express some of things Bazaar
supports (like empty directories, multiple authors and ghost revisions),
the fast-import format is the best we have today for interchanging
metadata among the various VCS tools. High quality fast-exporters and
fast-importers benefit us all, I believe.

Ian C.