Call for testing: cvs2bzr

[Ian Clatworthy]

Michael Haggerty wrote:
> Ian Clatworthy wrote:
>> Michael Haggerty wrote:
>>> 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.
> 
> Cool, thanks!  I committed your changes to trunk as r4871-4873 (with
> somewhat expanded commit messages :-) ).

Excellent. Thanks. Next step is to get the cvs2svn trunk released as
2.3.0 and uploaded into karmic. :-)

> I am curious why you did not include the discussion of fixup branches in
> www/cvs2bzr.html.  Don't similar considerations apply to cvs2bzr/"bzr
> fastimport"?  If not, how do you get around them?

I don't know enough about the problem yet but I assumed the fixup script
was git-specific. Is there a sample data set I can try importing into
Bazaar to better understand what we need to do and why? This problem
isn't one you can just make go away in an earlier pass is it? It seems
inefficient for each downstream tool to have to solve it independently.

> There sure is a lot of duplication between the three DVCSs.
> Medium-term, this will be a maintenance headache unless we can reduce
> it.  For example, we might think of having only one
> "cvs2fi-example.options" with a variable like target=(git|bzr|hg) at the
> top of the file then use "if target=='blah'" within the file in the few
> places where the three systems diverge.

That sounds a good idea. I suspect many users will stumble across these
tools by doing a Google search for cvs2xxx where xxx is bzr/git/hg. So I
suspect it's worth keeping the separate scripts & web pages though the
internals might be 99% in common.

Ian C.