Comparison with Git, Mercurial or Darcs?

[Mark Williamson]

<snipped content>

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

FWIW, Mercurial does record renames, whereas git does not record them at all.

Cheers,
Mark

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