

GNU Emacs is on Bazaar now - indy
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00812.html

======
jrockway
After 1000 email threads saying nothing and 3 years of work, GNU Emacs is now
using a slightly less-broken revision control system.

Everyone I know working on Emacs just uses the Git version and sends patches
against that. But we couldn't use Git for Emacs, because RMS does not like
Linus. Rational!

~~~
iambvk
I think it has more to do with Bazaar being a GNU project, not because RMS
does not like Linux.

~~~
nudded
You probably mean Linus? (makes a lot of difference)

If not <http://en.wikipedia.org/wiki/Linus_Torvalds>

------
artagnon
Thank God it moved out of CVS finally. It's still very difficult to contribute
though.

------
oomkiller
Too bad it's not git.

~~~
SingAlong
When I saw this post I was wondering what bazaar was. then it took me a few
seconds to google and figure out that GNU Bazaar is a version control system.
Why don't they use git? Anything good with bazaar?

EDIT: Just saw the Bazaar site. Even MySQL and Ubuntu uses them.
<http://bazaar.canonical.com/>

~~~
zaphar
Actually, bazaar has to be the most difficult and confusing VCS to use out of
all the options available. Git and HG are much saner options to use.

~~~
pohl
I just heard about bazaar. Could you elaborate? It feels very mercurial-esque
at first blush, and it would be nice to know what to look out for.

~~~
zaphar
Strange I could have sworn I replied to this yesterday but obviously I didn't.

Bazaar is a fork of arch. The last time i truly looked at it it was only
recently forked from arch. So you experience may vary.

At that time Bazaar was dog slow. Depending on who I ask it is either no
longer slow or it's still slow just not as slow. Since Git and HG both suite
my needs perfectly I've never bothered to check myself.

Bazaar uses multiple repository and wire formats none of which are completely
compatible with each other. For an application whose focus is distributed
collaboration this seems very much wrong.

It also from what I've heard is fragile when it comes to interrupted writes.
I've had stories of folks losing the whole repository because of this. This is
hearsay though so you can take it or leave it.

The sense I get is that both Git and Hg have a well exposed and understandable
theory of operation while Bazaar does not seem to have this and instead just
gives you a set of best practices. Again this is subjective and you may very
well find that its quite useable and understandable.

~~~
pohl
Thank you, that's exactly the kind of thing I was hoping you would share.

I wonder if you may be someone who used the software that was once also called
"Bazaar" but has since been renamed to Baz. It appears that the current
incarnation of Bazaar did not so much start out as a fork of arch, but as a
test-bed for features that would eventually make it back into Baz (which did
start out as a fork of arch). Apparently everybody decided to just ditch the
old codebase and work on the new one instead.

<http://en.wikipedia.org/wiki/Bazaar_(software)#History>

I like what I saw from looking yesterday. I especially like how it handles
renames and how it treats directories as first-class objects in the
repository. I'm also drawn to their concept of "bound branches", which I
suspect would be essential in one particular instance of SVN that I'm keen to
replace with something distributed but not totally anarchistic.

I think I'm going to keep Mercurial for my own personal use, for the sole
reason that you can get a _free private_ repository at bitbucket.org, but not
at launchpad.net or GitHub. If launchpad were to offer the same, that would
probably tip the balance towards Bazaar for me.

------
pieter
I hope this means bazaar performance has improved a lot. With the first
imports they created, running a 'bzr log' command could take more than a
minute before showing output. Funny enough, the developers didn't seem to
mind, because 'it's only a bit slower than cvs'

~~~
jrockway
It has improved, but not a lot. I find bzr to be unusable for working on Emacs
(so I don't use it).

------
blasdel
When I saw the headline I was afraid they'd switched to one of the ancient
directly-arch-derived DCVSes that had the same name (depressing that I
considered that plausible), but it looks like the FSF anointed Canonical's
most recent project a couple years ago.

~~~
zaphar
Bazaar is a fork of arch so you are correct in your initial assumption. It has
however been actively developed by Canonical for several years so it's
probably not as bad as it was then.

~~~
pohl
It seems that the current Bazaar was never a fork of arch. There was an old
fork of arch that was once also called "Bazaar", but it was renamed to "Baz"
and is no longer maintained. The current implementation is a new codebase. The
only thing it appears to have in common with the old fork of arch is the name,
which they must have carried forward for the sake of maximal confusion.

<http://en.wikipedia.org/wiki/Bazaar_(software)#History>

------
nuclear_eclipse
From the first follow-up mail:

 _'Then I noticed that "C-x v v C-c C-c" is enough to commit in CVS, but
perhaps not in Bazaar.'_

Wow.

~~~
geocar
Wow?

~~~
NikkiA
I imagine that nuclear_eclipse is commenting on the obtuseness of C-x v v C-c
C-c as a sequence of characters to tell emacs to commit a change.

Although it's not quite so daunting once you realise that C-x v is the
version-control prefix, and 'v' is commit individual file. C-c C-c is just the
command sequence to finish editing the commit message.

Once you leave apart the 'finish editing commit message' command, which is
really a seperate task, C-x v v is arguably obtuse as a way of saying commit
individual file, but on the other hand, C-x v as a prefix for all vcs related
functions is easy enough to remember, and 'v' for commit individual file is
easy enough to remember too.

In the microsoft world, 'C-x v v C-c C-c' would be replaced by a 10 page
wizard most likely, and be far more irritating.

[Please note, I do not condone the use of empty commit messages, that's a
heinous crime IMO]

Edit to add:

In my use of emacs with hg, I believe that that sequence will do exactly the
same as it does under cvs, and it's reasonable to believe that the vcs-bazaar
backend is no different either, so the complaint in the email is likely
invalid.

~~~
nuclear_eclipse
Thank you. That's exactly the explanation I was looking for, and you're right;
`C-x v` is much more reasonable as a hotkey for invoking vcs tasks, similar to
git integration in Vim, <Leader>-g-c for commit, etc. I was just blown away
imagining some superbly arcane key chord involving pressing and releasing
control _twice_ in a string of five letters... :P

~~~
silentbicycle
Specifically, "C-x v v" is C-x (extended commands), v (version control
prefix), v ("next action": do the next logical step for the current buffer,
usually committing).

C-c twice is used in several modes to mean "save and close out". It's also
what you hit to send an e-mail you're composing, for example. Holding control
and pressing c twice is pretty easy, just like whacking v twice for "next
action". (C-c usually prefixes commands specific to the buffer's mode, such as
"send the definition under the cursor to Python".)

If you ever forget any of this, you can type "C-x v" and then C-h (Help) and
it will list all of the keyboard shortcuts prefixed by C-x v, i.e., all
shortcuts related to version control. (I find VC shortcuts go straight to
muscle memory, but just in case.)

What NikkiA says above about those five keystrokes being a 10 page wizard in
other systems is spot-on.

