Comparison with Git, Mercurial or Darcs?

[Ben Finney]

Daniel Carrera <dcarrera at gmail.com> writes:

> Hi Ben,
> > * It respects the recorded history of changes
>
> Ok. I guess I see your point about "darcs amend". But "obliterate" is
> just "unrecord and revert", which bzr can do too.

It can, but it's not something I'd ever do except when something has
gone wrong in the VCS process. Instead, I'd simply fix the working tree
and commit a new revision.

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

I've never seen a good explanation for why it would be desirable for
anything involving a repository that might ever be shared with anyone —
and I think it's folly to decide forever that any particular repository
will never be shared.

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

You're not describing an “oops”; you're describing an unexceptional
“develop a feature in parallel with other development” workflow, which
in Bazaar is done my making a feature branch to explore the parallel
development of a feature. At any time (i.e. whenever you decide it's
time to do so), you can merge back and forth between one branch and
another.

So no, that's not what ‘bzr uncommit’ is for; that's what ‘bzr branch’
and ‘bzr merge’ are for.

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

Just use a separate branch. Commit changes freely into the branch, push
the branch for testing whenever you like, and any time it's ready (which
can be multiple times over its life), merge its changes back into the
trunk (which is also a branch like any other, from Bazaar's
perspective).

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

This seems to be common to just about everyone I've ever spoken to that
likes using Darcs; they don't do much sharing of their repositories with
others :-)

> Are revision numbers a hash or are they sequential?

The default presentation of a revision number (“revno”) is a simple
consecutive number, with revisions merged in from other branches shown
in dotted-tuple notation.

> If they revisions are universal, I imagine they would have to be a
> hash, like with Monotone.

Yes, the internal identifier for a revision (“revid”) is globally
unique. It's much longer than the revno, and can be displayed upon
request.

> Are shared repositories mainly to improve speed and space?

That's their main purpose, yes. However, they lead to related branches
residing within a common directory hierarchy, and that is also useful in
itself and leads to some nice features (like the ‘bzr branches’
command).

But yes, the main purpose is to optionally trade a slight increase in
complexity for improved space and speed.

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

No, a centralised workflow implies that the repository is in a central
location, and is the common commit location for numerous working trees
(used by multiple people, or multiple distinct machines by the same
person, or both). AIUI most DVCSen can't do this.
<URL:http://doc.bazaar-vcs.org/bzr.dev-html/en/tutorials/centralized_workflow.html>.

> > * Directories — even empty ones — are first-class citizens
>
> Ditto for Darcs. And again, I was surprised when I learned that other
> VCS tools don't do that.

I've had trouble using Darcs with empty directories; perhaps reverting
them, perhaps renaming them, I can't recall. It seems to be common
wisdom that one shouldn't have an empty directory in a Darcs project.
That might be obsolete cargo-culting now, I don't know.

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

Glad to help.

-- 
 \        “Like the creators of sitcoms or junk food or package tours, |
  `\         Java's designers were consciously designing a product for |
_o__)                       people not as smart as them.” —Paul Graham |
Ben Finney