Comparison with Git, Mercurial or Darcs?

[Daniel Carrera]

Hi Ben,

> It so happens one is in the works; it will likely be informative now
> <URL:http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html>.
> Please note that it's deliberately *not* given a misleadingly objective
> title :-)

I've read this page. It was alright.


> You might be interested in a discussion earlier this year, where a
> Bazaar user tried to figure out what was going on in Darcs user's heads.
> (Search for “Why Darcs users prefer Darcs over Bazaar”.)

Ok.


> I have recently been using Darcs, and many things about Bazaar are much
> better in my experience:

One correction from your list: Darcs does support renames properly. I
was surprised when I learned that Git and Mercurial have to do a
delete+add behind the scenes... Ugh...


> * It respects the recorded history of changes: When I make a change and
>  commit it, later changes don't threaten to alter or remove my change
>  from the ancestry. Changing history is possible, but is exceptional;
>  nothing like as common as ‘darcs amend’ or ‘darcs obliterate’ etc.

Ok. I guess I see your point about "darcs amend". But "obliterate" is
just "unrecord and revert", which bzr can do too. Perhaps you refer to
the fact that if I add features A, then B, then C, I can remove
feature A, so your history would change. I actually like this feature.


>  On the other hand, “oops” moments are easy to undo (‘bzr uncommit’).

I like that about bzr. The way I currently use darcs I actually use
that a lot. While I'm working on a new feature I enter a lot of
patches called "test", so I can push the changes to the test server.
When I'm satisfied with the work, I unrecord all the changes and then
re-record them into a nice set of patches.


> * It has a simple way to put some changes aside (‘bzr shelve’) while
>  committing the rest,

I like that too. It helps compensate for not having the
history-altering, cherry pick feature of Darcs.


> and it's easy to bring uncommitted changes from
>  one branch to another, if while working on the change there I decide
>  they make more sense here (‘bzr merge --uncommitted $OTHERBRANCH/’).

That is very interesting. I didn't know that. Does it work for things
you put on the "shelf"? Can I use this to push uncommitted changes to
my test server?


> * Bundling a set of changes together, or publishing a branch, is a
>  meaningful operation for the recipient: the aggregate effect of a set
>  of changes can, if desired, be examined just as easily as it were a
>  single change, rather than defaulting to see each individual change.
>
>  (It is the lack of this feature, IME, that leads Darcs users to use
>  ‘darcs amend’ so often, losing the existing detail and history of each
>  individual change.)

I don't think that's correct. In Darcs, a patch is either a primitive
patch, or a composition of patches. If you have patches A,B,C you can
treat their composition as a single patch. I can't say more because
I've never had to do this (I'm a solo developer).


> * Bazaar presents the ancestry of changes as UI: the natural way to talk
>  about changes is by their revision number in the ancestry, and a range
>  of revisions as they occurred in the branch (all commands talking
>  about revisions allow the same range-of-revisions specifier).

Are revision numbers a hash or are they sequential? If they revisions
are universal, I imagine they would have to be a hash, like with
Monotone.


> * Shared repositories are implemented well (and soon to be the default
>  in later Bazaar versions), and many Bazaar operations make it easy to
>  manage a collection of related branches in a repository; but none of
>  it is required.

Are shared repositories mainly to improve speed and space?


> * It allows for many different styles of workflow, smoothly and
>  compatibly and decided when necessary, not locked-in up front.
>
> * Especially, it allows for a centralised workflow when desired (‘bzr
>  checkout’ or ‘bzr bind’) without administrative overhead, and without
>  harming distributed operation.

I must be confused, but I would have thought that any distributed VCS
can act like a centralized VCS if you choose to use it that way.


> * Rename is a first-class operation, tracked like any other change and
>  maintaining consistent history of the file. This is a significant
>  lessening of tedium and worry, allowing for how filesystem entries
>  change over the course of working on a project.

As I mentioned earlier, Darcs does this. I was surprised that other
VCS tools do not. I expected all modern VCS tools to correctly
represent my intentions.


> * Directories — even empty ones — are first-class citizens of the
>  inventory, tracked like any other entry. Also lowers tedium, and
>  another example of Bazaar allowing for how people actually work with
>  files in a project.

Ditto for Darcs. And again, I was surprised when I learned that other
VCS tools don't do that.


> * The interface is far smoother and more consistent: it uses readline
>  for command-line input, it handles Unicode properly, common options
>  are sensible between commands, interfaces to external tools are done
>  well, etc.

Ok.


> * It integrates well with workflow tools. Loggerhead is a good web
>  interface to branches, Emacs VC mode supports Bazaar branches, Bazaar
>  can use just about any sensible diff/merge tool, and I hear users of
>  other workflow tools have similar happy stories.

Ok. Thanks for the info.


> I'm sure with more time I would think of other advantages. That should
> give you a taste, anyway.

Thanks. It was very informative and I learned several things I didn't
know before.

-- 
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.