Emacs chooses Bazaar

Remember that the goal of the GNU Project is to (someday... insert HURD joke here) give birth
to GNU.  And a GNU System will look a whole lot more like a system if all or most of it uses a
common version control system.  So for Emacs, viewed seperately, it might be seen as a
political decision yet from the pov of the GNU Project as a whole picking the GNU version
control system makes perfect technical sense as well.

And to a large extent that is due to Stallman. Or it seems so to me.

First of all, the split between emacs and xemacs happened because Stallman was adamant about
some minute issues with what was going to become xemacs and chose to disregard the technical
advantages it had over gnu emacs. A merger between them was possible back then and it did not
take place because of RMS. And that is the official explanation. It seems to me that in fact
Stallman is adamantly against anything he cannot control and his group did not conceive (the
anti-git attitude described in the article seems to be another example for that).

The split between emacs and xemacs was a Very Bad Thing (tm) because it takes a lot of effort
to evolve such a big project, keeping it both up to date and bug free. The manpower behind
both those projects is clearly insufficient (which is quite obvious considering the release
cycles) and keeping them separate is detrimental to both of them.  BTW, I used to follow
xemacs's newsgroup and I have seen its developers saying precisely the same - the split is
bad.

It seems that xemacs's development has practically stopped.  OK, so emacs won much to
Stallman's satisfaction. Good. I switched to emacs in order to use features like anti-aliased
fonts that are unavailable in xemacs. But even the most advanced emacs, custom compiled from
csv several months ago, has issues with TT fonts and anti-aliasing for non-Latin alphabet
languages. All the other editors on my Fedora 7 system deal perfectly fine with UTF-8 and
cyrillic characters, just the mighty emacs fails there.

And so it seems to me that even emacs's development is going to follow the development of
xemacs. And emacs is going to become more and more irrelevant to the young generation of
potential users. I mean that not because emacs fails me in particular, but - come on - in 2008
an editor has to deal with Unicode Just Fine (tm).

It's a good thing that we have Linus as a project leader for the kernel! With someone like
Stallman in control Linux would be doomed.

Did canonical give the copyright of bzr to the FSF ? Or do they still own it (which makes them
able to use bzr in non-free apps like launchpad).

Choosing a DVCS for a project is becoming a lot like choosing a coding style. You *have* to
pick one, but quibbling over their relative technical advantages is increasingly bikeshedding.
It is a waste of time and energy for everyone involved.

For a GNU project, choosing to use the DVCS that is part of GNU is as good a reason as any, so
I don't really see the point of this article, except to take cheap shots at Stallman and GNU
and their "agenda."

Well, arch/bazaar/bzr are much slower than git, but OTOH, they have a lot of room to improve
(unlike git, which has to take a lot of more pain to improve, since it is so far up the curve
already), and AFAIK, Canonical is working hard on bzr.

But the real timehog issue when converting from CVS to anything else less stupid (bzr, hg,
git, monotone, whatever) is that you look at the resulting history, and go YUCK!

One never really looks at history in CVS.  One tries to ignore it as best as one can, because
it is ugly as all heck.  That's not what happens when you get better tools where the history
and branching is actually useful for something.  So, suddenly, you ARE looking at all that
horrible snapshot of your past, and you cannot easily ignore its existence anymore.  It is
cleanup time, and that has to be done mostly manually, which takes time.

cvsps is a lifesaver helper, but it doesn't do nearly well enough to produce a very clean
history, especially when you have lots of branching.  

Well best of luck on Bazaar.  

I don't know if Bazaar has overcome the challenges created by using file-ids.  When I was
using tla file-ids made merges where you had two separate imports of the source base into one
tree next to impossible as tla would not admit the two files with different file-ids could be
the same.

If that challenge has not been overcome I would say that bazaar has considerably less
flexibility, the git and mercurial, and that may hobble it in the years to come.

I am curious about the DVCS preferences of other LWN readers from both technical and usability
standpoint (but not political). Which one do you prefer and why ? I think that the customary
high level of comments here may produce valuable insights.

I currently use Git both professionally and for my personal projects, after having evaluated
GNU Arch first. What attracted me to Git initially was that it seemed very clean and simple
conceptually and it had excellent low level and high level documentation. Another plus is that
transitioning from Subversion to Git was practically painless. My company has been using Git
too for about an year now and we haven't had any reason to regret that choice (quite the
contrary actually). In case you are wondering, we are doing Java development - not kernel :-)

I have always assumed that Mercurial would have done an equally good job, but it just happened
that I evaluated Git first.

At the time I also looked into Bazaar and Bazaar-NG, but I didn't find the same level of
documentation and clarity. What might have turned me off Bazaar is also its perceived relation
to GNU Arch, which I found impractical to use (the added difficulty compared to Subversion did
not justify the immediate gains).