Re: Switching CEDET from CVS to a Distributed VCS.

[Stephen J. Turnbull]

David Reitter writes:
 > On Jun 28, 2009, at 2:17 AM, Stephen J. Turnbull wrote:
 > 
 > >> 1. convert a git patch (git-format-patch) to a Bazaar merge  
 > >> directive?
 > >
 > > This is software, anything's possible.
 > 
 > I looked into it and it's fairly easy to do.  It would be for local  
 > use rather than for review by e-mail.

Instead of parsing the patch and/or log for meta data, applying the
patch and committing with "bzr commit"?  That's creative.  Good idea,
and good luck with it, it deserves a try.

 > > Useful?  Probably not.

OK, I retract that.<wink>

 > > 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.
 > 
 > This would be the ideal case and very, very convenient.  I hope there  
 > will be such a mirror [on savannah if possible],

This would be an amazing time sink for the Savannah people, is my
guess.  Not a good idea -- a lot of people would use it and conflicts
would be frequent, I think.  The extra bzr repos will stay way under
1GiB for the forseeable future, it's just not a big deal to keep them
locally.  Savannah should maintain the official format, period.

In theory you could use incremental fastimport format as a wire
protocol, but I wouldn't want to try that without core support from
the bzr devs.  Given how much effort they put into protocol and format
proliferation, I doubt they'd be happy to restrict themselves to a
simple NIH protocol.

 > but I'm not sure how it would handle merge failures, assuming that
 > this sync script runs periodically and without user intervention.

If it runs locally on your box while you're not working, it should
rarely have bad conflicts, and you should be able to resolve them
manually without trouble.  

 > The more frequently the git mirror is updated, the less likely it
 > is that a git->bzr merge fails.  If it does fail, I'm not sure how
 > to handle it well.  That's why I didn't pursue the idea so far.

The git->bzr pushthrough script would try to do a bzr->git merge
first, of course.  You want *all* failures to happen in your local git
repository because that's where you want to deal with amending commits
and similar history manipulations.  If that doesn't excite you, learn
to use bzr.  Trying to maintain bidirectional synchronization is going
to drive somebody crazy.