Emacs chooses Bazaar

By Jake Edge
March 12, 2008

The Emacs development process is undergoing some changes; Richard Stallman has handed off project maintenance duties, while a change in the version control system (VCS) seems to be in the offing. Some of the modernization suggestions made by Eric Raymond last December are taking root. Stallman has not completely stepped away from Emacs development—it's doubtful anyone expected him to—but his approach on how to choose a VCS for Emacs is raising a few eyebrows.

Currently, Emacs is tracked with CVS, but a distributed VCS (DVCS) is definitely planned down the road—how far is unclear at this point. In earlier discussions, Stallman was particularly interested in the offline capabilities of DVCS; being able to do commits, diffs, and see revision history while unconnected to the internet is a useful feature for him. Many other Emacs developers see a DVCS as a major upgrade to the development process, the question then becomes which DVCS to use.

The main contenders are git, Mercurial (aka hg), or Bazaar (aka bzr); there are other options, of course, but they were quickly eliminated due to speed or feature set issues. There was some hope that a comparative VCS study that Raymond was working on would help lead the project to the proper choice, but the study has been delayed—a major release of Wesnoth is underway which has taken Raymond from that task.

There were some discussions of the merits of the various systems but, in the meantime, Bazaar joined the GNU project which changed the equation somewhat. Stallman announced:

We should use Bzr because that is becoming a GNU package. GNU packages should show loyalty to each other when possible, and in this case it is possible.

As might be expected, short-circuiting a technical discussion for a political expedient is not met with universal approval. Juanma Barranquero sums up his (and others') objections:

What I'm trying to say is: I won't discuss which dVCS we choose (unless it makes Windows development a PITA). But I agree with Jeremy Maitin-Shepard that the cause of free software is strengthened by us selecting among the free alternatives the one that best serves our technical, not political, needs.

There is a certain irony in noting that one of the perceived weaknesses of git was its poor support for Windows development. It is certainly understandable, but the idea that one of the flagship GNU projects would make a decision based on tool availability for a proprietary operating system gives one pause. That isn't one of Stallman's requirements of course, he sees the decision as essentially a choice amongst equals:

We already know the most important thing about what we will find from a careful study of git, mercurial and Bzr. We will find that each has its advantages and disadvantages -- but none of them conclusive. Each will be preferred by some people, but any one of them would work out well enough.

As Thomas Lord (author of another GNU VCS, arch), points out, there is a cost to agonizing over a choice like this:

Probably so but any group of smart people could easily spend a year arguing about it. Not even a year arguing about which system is best but a year arguing just about what "best" means in this context.

Over-optimizing a choice like that can be a *huge* resource suck and projects and groups fail all the time because of falling into such traps.

No technical barriers to using Bazaar have been raised, it is, as Stallman asserts, a fairly arbitrary choice. Unsurprisingly, Stallman chooses the one that serves his agenda. The new maintainers, Stefan Monnier and Chong Yidong, presumably agree with that agenda, in any case they have not indicated any resistance to the choice.

So it seems that Emacs will be moving to Bazaar. Jason Earl has been pulling the CVS history into a Bazaar repository that should be available soon. The import process seems to be taking a fair amount of time—something on the order of a week—which is hopefully not indicative of the operational speed of Bazaar. Assuming the conversion works and developers can get their work done using it, this would be a pretty high-profile project to use it. Other GNU software may follow suit, which could be a big boost to the visibility of Bazaar; precisely what Stallman was aiming for.

to post comments

The political decision IS the best technical decision

Posted Mar 13, 2008 2:15 UTC (Thu) by jmorris42 (guest, #2203) [Link] (1 responses)

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.

The political decision IS the best technical decision

Posted Mar 13, 2008 22:00 UTC (Thu) by giraffedata (guest, #1954) [Link]

I don't see anything technical in your explanation. If there's a goal to create a system using only GNU tools, that's a political goal, not a technical one.

Is it really the goal of the GNU project to give birth to GNU (The GNU System)?. I thought Stallman announced that goal met long ago (with the Linux kernel being the kernel of the GNU system).

Emacs chooses Bazaar

Posted Mar 13, 2008 3:37 UTC (Thu) by zooko (guest, #2589) [Link] (5 responses)

I'm very interested in "high profile design wins" for decentralized revision control tools. Let's see, git has Linux (or does Linux have git?), X.org, OLPC, and VLC and many others (from http://git.or.cz/gitwiki/GitProjects).

Monotone has, let's see Pidgin (formerly GAIM), Dropbear SSH, and those're really the only ones that I recognize (from http://www.venge.net/mtn-wiki/ProjectsUsingMonotone).

Mercurial has Xen, OpenSolaris, Mozilla, OpenJDK, ALSA, NetBeans, XEmacs and Xine and many others (from http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial).

Bazaar has (from http://bazaar-vcs.org/WhoUsesBzr).... Um. Hm. I wouldn't call any of these "high profile". GNU MailMan is probably the most important one from this list to me personally.

Then there's darcs -- the one that I use and contribute to -- (from http://wiki.darcs.net/DarcsWiki/ProjectsUsingDarcs): not much unless you count ghc. (By the way, the project that is my passion and my day job is on that list: http://allmydata.org. Not "high profile" of course.)

So I hereby crown Mercurial as the winner of the First High Profile Decentralized Revision Control High Profile Project Race, March, 2008.

Of course, this list is just showing which projects that I personally consider to be "high profile", i.e. familiar and interesting to me. I'd be happy to hear about other people's views on these lists.

Emacs chooses Bazaar

Posted Mar 13, 2008 6:10 UTC (Thu) by Cato (guest, #7643) [Link] (2 responses)

I think that these Mercurial-using projects count as high profile: Drupal (popular blog
software), APT (used by Debian and Ubuntu for package management).  Doesn't change your
conclusions though.

Emacs chooses Bazaar

Posted Mar 13, 2008 6:10 UTC (Thu) by Cato (guest, #7643) [Link]

Sorry, that should read 'Bazaar-using'...

Emacs chooses Bazaar

Posted Mar 20, 2008 11:22 UTC (Thu) by jpetso (guest, #36230) [Link]

Drupal is neither a "blog software" (more a general purpose web app 
framework that you can bend to do everything you'd like to) nor is it 
using Bazaar. There's a Bazaar-powered Drupal import mirror on Launchpad, 
and some developers use that one to create patches, but that's it. 
Everything "official" in Drupal still runs CVS.

Emacs chooses Bazaar

Posted Mar 13, 2008 14:34 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

Ubuntu uses bazaar(-ng). Features of launchpad.net are centered around bazaar.

Emacs chooses Bazaar

Posted Mar 13, 2008 17:45 UTC (Thu) by zooko (guest, #2589) [Link]

Oh, darcs is used by Buildbot.  I think Buildbot is great!  Buildbot counts as "high profile"
in my book.

I am afraid emacs is becoming irrelevant

Posted Mar 13, 2008 8:51 UTC (Thu) by mmarkov (guest, #4978) [Link] (7 responses)

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.

I am afraid emacs is becoming irrelevant

Posted Mar 13, 2008 11:40 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Among the major challengers to emacs is the immersive IDE:
Tim Bray:
>The feature that tempted me away from Emacs is the Navigator; you just hover over this little
button and this thing pops up... a really nice way to navigate around a big honkin C file.
http://www.tbray.org/ongoing/When/200x/2008/03/11/NB6-1-C

However, if you've hung out in #emacs on freenode, or looked at www.emacswiki.org, you
probably guess that emacs will continue to improve things like the Emacs Code Browser to stay
competitive.
Now and then, working without an X session seems a release...

I am afraid emacs is becoming irrelevant

Posted Mar 13, 2008 14:03 UTC (Thu) by wlach (subscriber, #23397) [Link] (4 responses)

Speaking of, does anyone know why GNU Emacs seems to have won out over XEmacs? If you'd asked
me a few years ago, I would have thought that the latter's more open development model would
have pushed it ahead. I'm surprised to see most of the exciting feature development work
(Unicode, Xft fonts) going into the GNU version.

I am afraid emacs is becoming irrelevant

Posted Mar 13, 2008 22:10 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

It died largely because it had, oh, one really active developer at any 
given time, and right now it has none (Ben Wing being too busy).

It's reanimatable, of course: it's free software...

xemacs liveness

Posted Mar 17, 2008 12:10 UTC (Mon) by eru (subscriber, #2753) [Link] (1 responses)

While not an xemacs user (maybe I should become one just to be contrary :-), this thread prompted me to visit its site out of curiousity. Doesn't look so dead to me, eg. there is more traffic in mailing lists than in many other FOSS projects (eg see http://calypso.tux.org/pipermail/xemacs-beta/2008-March/thread.html). The latest stable release is 1/2 years old, which also is not so unusual.

xemacs liveness

Posted Mar 17, 2008 20:16 UTC (Mon) by nix (subscriber, #2304) [Link]

The pace of development at the moment is very, very slow. The unstable 
release is moving at the speed of most projects' stable releases, because 
nobody working on it has the time to do major development. (I include 
myself in this to some extent. I don't have hg commit privs largely 
because I, sigh, wouldn't have the time to do anything with them. I need 
some way to double the number of hours in the day, or perhaps triple 
them...)

But it works, and is revivable if someone steps up to the plate *looks at 
self guiltily*

I am afraid emacs is becoming irrelevant

Posted Mar 13, 2008 22:11 UTC (Thu) by nix (subscriber, #2304) [Link]

btw, XEmacs 21.5.28 has support for both Unicode and Xft fonts (not 
flawless, but working well enough to use).

I am afraid emacs is becoming irrelevant

Posted Mar 13, 2008 21:51 UTC (Thu) by skissane (subscriber, #38675) [Link]

Stallman has his flaws, as do all of us, but I think you are being excessively harsh on him. I think there were multiple reasons for the GNU/XEmacs fork. Factors included technical disagreements, disagreements over project management style, and disagreements over legal issues (i.e. GNU wanted copyright assignment to the FSF, something which several XEmacs developers were unwilling or unable to do.) I think the first two could be sorted out over time (look at the history of GCC/EGCS), but it is the legal disagreements which have served to make the divorce permanent. As I understand, Stallman has previously received legal advice that the FSF's ability to enforce the GPL on GNU packages is enhanced by having the copyright wholly owned by one entity. Whether this is good advice or not (I suspect that as the courts get more exposure to the GPL it may be less of an concern), you can understand Stallman's point of view.

I think in the end the reason why GNU Emacs seems to have mostly won out has been more critical mass. XEmacs certainly pioneered a number of interesting features, and even if (due to legal concerns) its code has not been incorporated into GNU Emacs, certainly the design & implementation experience of the XEmacs project has been beneficial to GNU Emacs over time. And forks in open source projects are not a purely negative thing — sometimes it is useful to be able to try competing approaches to the same problem.

And I don't think which choice of revision control system the GNU project makes is really a big issue. Its not a case of making a technically inferior due to political concerns. When faced with a choice between several technically excellent products, its often a good idea to turn to non-technical considerations to make a decision, because if you insist on deciding purely on technical merits, you run the risk of turning into Buridan's ass.

Emacs chooses Bazaar

Posted Mar 13, 2008 8:51 UTC (Thu) by bboissin (subscriber, #29506) [Link] (3 responses)

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).

Emacs chooses Bazaar

Posted Mar 13, 2008 9:16 UTC (Thu) by diocles (guest, #46753) [Link]

Canonical kept the copyright.

But, even if they didn't, they would still be able to use bzr in Launchpad. For starters, bzr
does not necessarily have to be so closely tied into the Launchpad code such that the terms of
the GPL would apply to the combination. Secondly, they're not distributing binaries or source
of Launchpad, so they would not have to release the source anyway.

Launchpad isn't non-free as such, it's just another big custom web-app. (But that's a whole
different debate.) I'm told the Launchpad team are still working hard on getting the code into
a good enough shape to release.

Emacs chooses Bazaar

Posted Mar 15, 2008 17:32 UTC (Sat) by intgr (subscriber, #39733) [Link] (1 responses)

But canonical does appear to be relicensing the code for proprietary software; refer to their web site:

[...] If you want to embed Bazaar into your products under a different license, please contact us.

How could that ever be appropriate for a GNU project is beyond me.

Emacs chooses Bazaar

Posted Mar 16, 2008 1:26 UTC (Sun) by nix (subscriber, #2304) [Link]

Um, the license grantback you get when you fill in a copyright assignment 
form has always (as far as I know) allowed you to do that (with the stuff 
you originally had copyright on before signing it over).

Emacs chooses Bazaar

Posted Mar 13, 2008 16:15 UTC (Thu) by jordanb (guest, #45668) [Link] (1 responses)

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."

Emacs chooses Bazaar

Posted Mar 13, 2008 17:35 UTC (Thu) by jake (editor, #205) [Link]

> I don't really see the point of this article, except to take cheap shots at Stallman and GNU
and their "agenda."

No cheap shots were intended, nor do I think there are any in the article.  Sorry it seemed
that way to you, but I was just trying to report on what was going on in the project.

jake

Emacs chooses Bazaar

Posted Mar 13, 2008 16:27 UTC (Thu) by hmh (subscriber, #3838) [Link] (4 responses)

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.

Emacs chooses Bazaar

Posted Mar 14, 2008 1:44 UTC (Fri) by dmarti (subscriber, #11625) [Link] (2 responses)

For me, anyway, the size and speed of git makes it practical to use for stuff that I would not have had under revision control, such as small web projects and article notes. I also have "etckeeper" by Joey Hess installed on a new machine, to keep /etc in git. (I should write something about this one -- it's hooked into apt so you get a commit of config file changes that happen on package install. Very nifty and potentially work-saving, though I haven't been running it very long and haven't rolled anything back.) So it's natural for me not to have to learn two DVCSs thoroughly, and use git for larger-scale projects too.

Emacs chooses Bazaar

Posted Mar 14, 2008 3:34 UTC (Fri) by njs (subscriber, #40338) [Link] (1 responses)

>For me, anyway, the size and speed of git makes it practical to use for stuff that I would
not have had under revision control, such as small web projects and article notes.

I don't understand what you mean here.  Small projects are exactly those where all VCSes can
perform all operations instantaneously; git's optimizations are all about scaling up?

Emacs chooses Bazaar

Posted Mar 14, 2008 3:58 UTC (Fri) by MarkWilliamson (guest, #30166) [Link]

I don't know what the OP meant to say, but to me the modern DVCS systems 
seem much more practical for keeping small, simple projects in than, say, 
CVS or SVN.  They keep all the repository state in a single directory, 
within your working tree; there's no separate repository.  In this 
respect it's rather like using RCS (except better!), which always used to 
be my solution to revision controlling single files / small groups of 
files.

Emacs chooses Bazaar

Posted Mar 14, 2008 3:31 UTC (Fri) by njs (subscriber, #40338) [Link]

"arch/bazaar/bzr" is probably not the best way to think of them -- there are two completely
unrelated VCS designs, one called "arch" and "bazaar", and another called "bzr".  "bzr" is far
more closely related to mtn/hg/git than it is to "bazaar".

Yes, this is confusing.  For most purposes the best solution is to just forget "arch" and
"bazaar" ever existed, since they're now only of historical interest.

Emacs chooses Bazaar

Posted Mar 13, 2008 16:29 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

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.

What do LWN-ers use ?

Posted Mar 13, 2008 18:25 UTC (Thu) by mikov (guest, #33179) [Link] (14 responses)

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).

What do LWN-ers use ?

Posted Mar 14, 2008 13:49 UTC (Fri) by Wummel (guest, #7591) [Link] (1 responses)

Git lacks an Eclipse pluging so my Java projects are still stored with SVN. For projects that
do not need Eclipse I use git though.

And using git-svn is also a very nice way to track upstream SVN repositories while also
maintaining a set of local patches.

git works in Ecplise

Posted Mar 14, 2008 15:16 UTC (Fri) by deleteme (guest, #49633) [Link]

Git for ecplise is available. But using something that really means it when it says This package might eat your files, and has no support for merging isn't that fun.. But actually almost useable, if you can stand to use pre alpha stuff.

What do LWN-ers use ?

Posted Mar 14, 2008 20:24 UTC (Fri) by felixrabe (guest, #50514) [Link] (1 responses)

Git.

Because it's the first and only DVCS I: got interested in thanks to LWN / learned / found
plenty of good documentation for.

As far as I'm concerned, I find it cleverly implemented (totally fits into the "one small tool
for a given-task" Unix mentality), find it's interfaces easy to learn and easy to combine with
other Unix tools, and thus like to use it wherever possible.  I have no idea about the other
DVCS', whether they are similar enough, but I also positively love speedy applications, which
makes me stick to Git for the foreseeable future.

What do LWN-ers use ?

Posted Mar 14, 2008 20:30 UTC (Fri) by felixrabe (guest, #50514) [Link]

Btw I found no issues with Git on Windows with my small scale projects other than the
operating system :)

What do LWN-ers use ?

Posted Mar 16, 2008 15:30 UTC (Sun) by astrophoenix (guest, #13528) [Link] (9 responses)

I have settled on mercurial. darcs was a close contender. I love darcs' ability to pull a single patch. But, mercurial is fast, Fast, FAST, has lots of developers, plugin support, is written in python, fully cross-platform (I have to deal with some windows folks at work), and has some really great extensions already like view (inspired by gitk), forest (for handling multiple modules in a really nice way), the mercurial queue (handling patches on top of history like quilt but much more convenient), and transplant (for cherry-picking any patch you need to).

on top of that, mercurial has the best documentation I've seen for any DVCS, take a look at the book written about it.

If darcs were faster and had a view/gitk program, and was cross-platform for real (i.e., handled the line ending issue) I might revisit it again. hmm, that list got longer than I intended it to. :)

I also was intensely interested in git, but I just couldn't do it. I tried when it first came out, and used it for a simple project with lots of files where I knew there wouldn't be any branching. so I got a feel for the performance of pulling lots of patches (fast). I tried again about 3 months ago, saw improvement, but still couldn't do it. I felt it was easy to do easy stuff, but anything past that, you really had to jump off a cliff of a learning curve, and there were sharpened stakes at the bottom of the cliff!

the poster I'm replying to said there is great documentation for git now... please look at the mercurial book and then post a link to documentation that compares to that, for git. I haven't been able to find any good source of documentation at all, past man pages for some of the commands, and a couple of tutorials that get you into the absolute basics. nothing for how to deal with the aforementioned cliff with spikes at the bottom. :) I really would like to learn git though. but mercurial is just as fast as git, and MUCH easier to master.

What do LWN-ers use ?

Posted Mar 16, 2008 18:24 UTC (Sun) by johill (subscriber, #25196) [Link] (8 responses)

For me, the big problem with mercurial is that it stores all state for each repository and has
no way of packing and/or combining things. Hence, every checkout takes the full history, where
with git you only need the additional objects and make it refer to another tree for most
objects, so another working tree is cheap, where with mercurial you copy all history again.

What do LWN-ers use ?

Posted Mar 16, 2008 18:49 UTC (Sun) by astrophoenix (guest, #13528) [Link] (2 responses)

interesting. I can tell you that when you do keep the full history around, mercurial is a lot more space-efficient than git. and if you are making a new copy of a tree on the same filesystem, mercurial hard-links everything, so it's still cheap.

What do LWN-ers use ?

Posted Mar 17, 2008 4:10 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

git has the option to use hard links when doing a clone. I've also seen some very spectacular
compression achieved with git packs. are you possibly comparing to a git repository that
hasn't been packed?

What do LWN-ers use ?

Posted Mar 19, 2008 20:36 UTC (Wed) by astrophoenix (guest, #13528) [Link]

you're probably correct; I was probably comparing an unpacked git repo to 
a mercurial repo when I said mercurial took less space.

What do LWN-ers use ?

Posted Mar 16, 2008 19:03 UTC (Sun) by astrophoenix (guest, #13528) [Link]

more precisely, mercurial hard links all the history files (not the working copy files).

Space-efficient checkouts

Posted Mar 17, 2008 5:31 UTC (Mon) by kevinbsmith (guest, #4778) [Link] (3 responses)

I could be wrong, but my understanding is that bzr is one of the few (or maybe the only?)
d-vcs that can share the history between multiple branches/checkouts, even under MS Windows
(without hard links or symlinks). If you are serious about cross-platform support, that's a
big feature, because you want branching to be cheap for everyone on all platforms.

If anyone can confirm/refute whether bzr and/or other systems can in fact do this, please do
so.

Space-efficient checkouts

Posted Mar 17, 2008 9:20 UTC (Mon) by wingo (guest, #26929) [Link] (2 responses)

I use bzr on a number of projects, but I've found that git's in-place branching is much more
useful than bzr's shared-repository code. My brain and fingers don't do so well with multiple
directories for a project; it's much easier for me to have one directory and switch branches
at will.

Aside from that, having the set of branches stored in the repo itself is good from a
discoverability POV.

Anyway, my point was that shared repositories are less interesting when you have in-place
branching. (I like both bzr and git, so no flames please.)

Space-efficient checkouts

Posted Mar 17, 2008 20:39 UTC (Mon) by incase (guest, #37115) [Link] (1 responses)

I still don't use a dVCS, but I find in-place branches difficult for me. Not conceptually, but
I like to keep different branches around, like my Debian packages: I sometimes maintain both a
backport to Debian stable and a version of the same package in unstable (i.e. the current
development part). I would find it quite inconvenient to commit anything I currently try in
the development branch only to be able to safely switch to the backport's branch. However, I
know that some people like to commit any (reasonably sized) changes they do, while I usually
like to try my changes at least on a very basic level before committing and doing more
extensive tests. This sometimes means that I have changes uncommitted for days at a time.
Certainly something many developers don't like to have.
Anyway, based on this, I like mercurial better than git.

On the local storage of all the history vs. referencing the remote repository, I also prefer
the mercurial way. Once I cloned/branched a remote repository, I have all history at my
fingertips (not just the commit messages), even if the remote repository becomes unreachable
for some reason.

Space-efficient checkouts

Posted Mar 20, 2008 11:15 UTC (Thu) by bluss (guest, #47454) [Link]

A git user would use a "topic branch" for each such string of unacknowledged changes. Then
when you have evalutated the changes just merge the branch or delete it at will.

Arguably a system that doesn't let you commit for days reminds me of svn, patch+diff or
similar old-fashioned systems.

Speaking of comparing DVCSes...

Posted Mar 17, 2008 1:03 UTC (Mon) by maney (subscriber, #12630) [Link]

I ran across this series of blog posts a few days before this article arrived, and have been meaning to find it again ever since. Elijah makes a number of interesting observations, including identifying an axis along which many of the systems sort themselves out, with corresponding differences in what they can and can't do (without accessing external resources). And while the idea of "limbo" wasn't new, discussing it explicitly does clarify things, and it's another axis along which some DVCSes differ.

This is, BTW, an example of something that existing blogware doesn't seem to handle well - the articles probably read more smoothly in order, but they're presented exactly backwards (at least by default). Well, that can work, too - I wandered into these somewhere in between the ends and wandered around kind of randomly. :-)

Emacs chooses Bazaar

Posted Mar 17, 2008 9:58 UTC (Mon) by eru (subscriber, #2753) [Link]

The world is not likely to ever standardize on any One True Operating System, not even if the choice were only between different free operating systems. So choosing a version control system that can demonstratably handle different underlying OS'es makes good technical sense.