Insights from bzr newbie coming from git

[David Allouche]

This morning I chatted with AfC, who is trying bzr and has some git
experience. He was very articulate, to the point that I ended up pasting
several of his messages in Tomboy for future reference.

Here is a summary of the interesting points in this discussion, and my
interpretation of them. Timestamps are UTC+1.

> (12:18:32) AfC: quicksilver: yeah, I'm not so sure I agree with that
> one. The git guys had a good point there. Relying on rev nos from
> some hypothetical master | central repository is a bit vague.
>
> (12:41:55) AfC: ddaa: I actually like the
> andrew at operationaldynamics.com-20061130081240-0fdbc9971670291a
> revision ids that bzr vis shows

Git people feel uncomfortable with revnos  because they are perceived as
"not dependable". It's interesting to see that bzr revids are actually
lovable, and that "unique enough initial digits of the hash" is not
universally perceived as a killer feature.

> (12:49:11) ddaa: AfC: that's really interesting, what do you find
> clunky, apart from the discomfort of using revnos?
> 
> (12:50:22) AfC: ddaa: the branch thing. That's really got me stymied.
> I think you came in at the tail end of our conversation earlier, but
> there's one behaviour that git encouraged that I'm now kinda in the
> zone for and really really fighting at the moment, and that's
> switching a given checkout between various branches "in-place"

Switch is cool. But bzr requirement to have separate branches (and
likely a repository as well) makes it hard to use. Multi-heads would
make it possible to combine the efficiency of switch with the simplicity
of standalone branches.

When we have tags, we might provide multi-heads as "magic tags", that go
forward with commits. Was this discussed before?

> (12:51:45) AfC: ddaa: [but, before I forget, the plugin thing is
> actually distracting. It's hard to tell what's a blessed, tested,
> official bzr command and what is some bakers dozen wacko not really
> implemented command that'll corrupt your repository. I would suggest
> that that isn't such a good thing]

Bzr effectively has a n-tiered distribution system: the core, bzrtools,
a few "cool plugins", and a lot of "random stuff". It's a trade-off that
was made consciously to deal with conflicting requirements of being
simple, reliable and consistent in the simple case, and yet allow easy
access to features with less polish or problematic dependencies for
people who do need it.

The trade-off looks like a good one to me, but maybe there can be ways
to make the situation more transparent to new users.

> (12:52:41) AfC: ddaa: well that was 20% of the problem - you start
> out with a `bzr init` created repo+branch+checkout all in one place.
> Turning that into a repo-elsewhere +
> branches-elsewhere-in-the-repo-maybe + checkout-but-light
> 
> (12:52:44) AfC: is VERY non trivial

That's definitely a problem. Many newbies I interact with quickly want
to go past the simple standalone branch setup, and then they hit a
frustrating hump in the learning curve.

It is not clear whether this is a primary issue, or just fallout from
lacking multi-heads. Any opinion?

> (13:00:31) AfC: [oh, I would note on the previous topic that bzr
> visualize only reports revids, and then you have to somehow translate
> to revnos because -r doesn't take a full revid as an argument. Now I
> know about "revid:", but the --help doesn't seem to say that
> anywhere]

The lack of discoverability of revspecs has already been discussed to
death and back. But it has not been fixed yet. In 0.13.0candidate1 the
help of merge and branch still does not hint of the ability to identify
revisions by revids.

I could not find a bug about this on Launchpad. Should I file a bug?

-- 
                                                            -- ddaa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061130/1b52a914/attachment.pgp