Re: Switching CEDET from CVS to a Distributed VCS.

["Stephen J. Turnbull" <stephen@xemacs.org>]

David Reitter writes:
 > On Jun 25, 2009, at 1:48 PM, Stephen J. Turnbull wrote:
 > > I believe Bazaar now supports fastimport format in both directions.
 > >
 > > Interaction between git and Bazaar probably means you lose/munge
 > > VCS-specific metadata (Bazaar cares about revision numbers while git
 > > doesn't support them at all, and the revision ID formats are
 > > timestamp-specific in each VCS, so converting those in a
 > > roundtrippable way would require great care) in each direction, but
 > > with minimal care you should be able to preserve the history dag and
 > > core meta data (author information).
 > 
 > fast-import (bzr->git at least) keeps an index to facilitate fast  
 > incremental exports.
 > Suppose one has a commit in the git repo to be committed to the Bzr  
 > repo, would it be possible to
 > 
 > 1. convert a git patch (git-format-patch) to a Bazaar merge directive?

This is software, anything's possible.  Useful?  Probably not.  I
don't see why you'd want to do anything other than maintain pairs of
bzr-git bidi mirrored branches.  In particular, merge directives are
most useful if you have a formal review process and a patch queue
manager such as Bundle Buggy or PQM.  That's just so not Emacs.  Emacs
has committers, not reviewers.  Maybe CEDET has a more formal process,
but you still wouldn't want to use merge directives without automatic
help AFAICS.

 > 2. use fast-import/export to export just the patch?

I really don't see why you'd want to do this.  "Just patches" makes
a lot of sense if your name is Andrew Morton.  (Not necessarily
literally, but someone whose mission in life is managing such a
patch-based workflow.)

Agreed, compared to ideal, or even to git, bzr's performance sucks,
even after a 500% or so speed up in certain operations.  But
realistically, it's usable, unless you want to hang `(shell-command
"$VCS commit -a -m autocommit;$VCS log -10")' on your save-buffer-hook
as I do.

What bzr cannot do very well that git excels at is editing history.
bzr is a FORTRAN derivative.  For all practical purposes, unless
you're a bzr.dev, history is a linear array in each branch.  Unless
you really really know what you're doing, you don't want to do
anything but work linearly in each branch, and occasionally merge to
mainline.  But guess what?  Most people just want to work linearly in
each branch, and occasionally merge to mainline.  I see no problem
here, do you?

git is a LISP derivative.  If you are comfortable with cons, setcdr,
and mapcar, then you will be comfortable with git-commit, git-rebase,
and git-filter-branch.  And you will feel the power.  But hey, every
minute you spend playing with git is a minute you're not hacking
Emacs.  Is it worth it?

Seriously, if you're a git aficianado, set up the bidirectional
mirror, create a pushthrough script that pushes from the git repo to
the local bzr repo, and on from the local bzr repo to Emacs Central,
and (my best guess) be happy.  If you then find you're not happy yet,
*then* it's time to discuss these optimizations.  Both git and bzr are
flexible enough that you can be confident of finding ways to
streamline later if it's necessary.