Comparison with Git, Mercurial or Darcs?

[Daniel Carrera]

Hi Stephen,

> Most of the updated comparisons I'm aware of have to do with
> performance, not workflow.

Ok. I realize that that's important for big projects. My projects are
so small that any VCS will be fast enough.


> The big selling point for many users is that Bazaar has the best
> facilities for repo-agnostic operation.  You can use bzr as a front
> end to svn, git, and maybe hg repos with very little change from the
> native bzr interface.

That's interesting. I didn't know that.


> bzr also has a plethora of options for automating workflow.  You can
> operate in Darcs-style repo = branch = workspace, or you can operate
> in Subversion-style workspace checked out from branch contained in
> repo.  There is some capability for git-style "multiple named branches
> in one repo = workspace" (I forget the Bazaar jargon for this).  All
> of these are accomplished by choosing an appropriate configuration of
> repository layout (this is not hard or complex) and options in the
> bzrconfig files.  Then the usual primitives (commit, checkout, push,
> pull) do the right thing.

Ok. That's also very interesting. It sounds complex, but I don't have
to worry about it. I'm sure bzr would work fine in its default
configuration.


> Of course there is no Darcs-like patch theory.  I wonder if you'll
> actually notice that in practice, though.

I think the only time I'll notice is when I commit changes A, B, C and
then I decide i want to uncommit change A. I do this quite often, but
I think Bazaar's "shelve" feature might give some of what I want.


>  > I would also be interested to hear any personal perspectives as to why
>  > you use Bazaar.
>
> Because my upstream does. :-)

Heh.


> AFAICT Darcs' theory of patches *in practice* depends heavily on the
> fact that two changes touching different sets of files don't conflict,

I've never heard this view before. When I move patches around, they
often touch the same file. I never really think about which files are
touched.

> and on what patch(1) calls "applying with offset".  This is no
> different from what is available in bzr, git, or hg.  All of them have
> cherrypicking, rebasing, and patch reversion commands that work just
> about as well as Darcs does in my experience, and do it one heck of a
> lot faster.  Darcs may do better in some corner cases, but I doubt
> that it saves enough time to make up for Darcs' general slowness.

Can you tell me how I can uncommit a change that I committed a few
steps ago? Just take the simple use case: I commit change A, then B,
then C, and I want to uncommit A. I do this very often. It makes my
whole workflow a lot simpler. Can I do this with Bazaar?

For the work I do, whatever slowness Darcs might have is completely
undetectable. But I know that Darcs is not suitable for very large
repositories or very long histories. But I'm a solo developer, so I
don't have that problem.



> However, the Darcs UI is very poor at examining history.  Basically,
> Darcs does not (and cannot, with current metadata structures) provide
> a way to give an accurate historical view of the commit DAG (and AFAIK
> there's not even a standard way to show the patch dependency DAG).

I'll take your word for it. I've never needed to look at the commit DAG.


> If you have a very linear development process, OR a "quantum" development
> process (ie, like your web developer process you have a "cloud of
> virtual patches" at any one time, and after a bit of experience you
> decide which ones to make permanent and which to revert) that's very
> "broad" in the number of patches being worked on at one time, but you
> rarely if ever worry about history a few months back, the history DAG
> will not be missed.

Yeah.


> bzr shines at displaying history.  It is very good at showing you what
> you've accomplished in your current branch and relating that to other
> lines of development.

Ok.


>  > I can add patches A, then B, then C, and then remove patch A to
>  > make a change.  Bazaar's "shelve" feature is similarly very
>  > interesting. I just wish I had a way to upload stuff on the shelf
>  > to the test server other than using rsync.
>
> I guess you're looking for "looms" (sort of like quilt or Stacked Git
> on steroids) or "pipes" (sp?) (very like Mercurial queues).  These
> allow you to maintain several lines of development in a single
> workspace in a very structured way, all under revision control.
> Because they are under revision control, you can push to the test
> server, then checkout the pieces you're interested in testing.
>
> These are not yet standard features of bzr, unfortunately, and at
> least looms are somewhat underdocumented.  However, they are quite
> stable and their users are very pleased with them.

I've never heard of looms but I would be interested to learn more
about them. Maybe they would be an alternative for me. Do you know of
any page that explains that a loom is?

Thanks for the information.

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