GNU Emacs is on Bazaar now | Hacker News Reader

GNU Emacs is on Bazaar now

lists.gnu.org

30 pointsindy26 comments

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!

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

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

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

Since Bazaar "transparently supports foreign branches for Subversion, Git and Mercurial repositories", I have to ask: does it matter that they don't use Git?

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

Too bad it's not git.

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/

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.

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.

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.

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.

We use launchpad (i.e. bzr) for an open source project. It works and it does what you'd expect it to. Then again, it is a small project with simple needs.

Bazaar caught me by surprise, too. I've been enjoying the DVCS world lately, having finally decided that I had outgrown SVN.

Mercurial grabbed me more than Git did. My first experience with Mercurial was very natural. Everything that I tried worked the first time in the way I first tried to do it. Git left me fumbling about and googling for answers, but I was able to acclimate quickly. Ultimately, I decided that I would need to use both: Mercurial for my own tastes, and Git just because it's the dominant player.

Bazaar looks like a strong competitor, even for Mercurial, in terms of usability.

Knee-jerk much?

No, I've used bzr before, and much prefer git.

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'

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

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.

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.

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

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.

Wow?

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.

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

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.

Exactly, committing with no message is poor practice.

That should be: "C-x v v <Type Commit Message> C-c C-c"

Reply on news.ycombinator.com