Re: Switching to bzr: what remains to be done?

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Another issue that AFAIK nobody has worked on, is how are we going to
 > handle the Gnus<->Emacs synchronization in the future.  I expect this to
 > be doable somehow, maybe by still going through Arch, but of course it
 > would probably be preferable to do it directly within Bzr, and in any
 > case it will require for someone to figure it out.

Sorry I can't help with the actual work, but I have some related
experience to describe.

cvs2svn did a great job for me converting the XEmacs repo to git's
fastimport format.  The XEmacs repo is an unholy mess, too, I was
quite surprised at how well cvs2svn handled this.  It has some kind of
update facility (AIUI fastimport is just a format for describing
commits).  I'm not sure if bzr has bulletproof fastimporter yet, but I
know this has come up on the list lately.  Anyway, I recommend a look
at cvs2svn, and maybe encouraging bzr work on fastimport.

tailor is another option, but I've found tailor to require a lot of
care and feeding, at least at first.  The receiving backend was
Mercurial which was implemented as a plugin from the libraries, not by
invoking hg itself.  However the command line interface is more
stable, which seems to be the source of my difficulties.

 > We have lived without any renaming or merge info in our CVS,

Going through git or another VCS that does automatic rename detection
might be an option.

 > Also, being able to update the Bzr repository incrementally from
 > subsequent updates in the CVS is not indispensable, but it would
 > be helpful to make the transition easier.

I think pretty much all popular tools can do this.