Insights from bzr newbie coming from git

[Jan Hudec]

On Thu, Nov 30, 2006 at 10:48:41AM -0600, Matthew D. Fuller wrote:
> On Thu, Nov 30, 2006 at 02:44:31PM +0100 I heard the voice of
> David Allouche, and lo! it spake thus:
> > 
> > Multi-heads would make it possible to combine the efficiency of
> > switch with the simplicity of standalone branches.
> 
> Having the ability to have multiple heads on one branch (as opposed to
> the slightly different case of multiple heads treated fully as
> different branches) allows other stuff too.  Monotone does that, and
> it opens up the door to <http://venge.net/monotone/wiki/DaggyFixes>.

Since branch is a pointer to head (and just that) by definition, it
would not be multiple heads per *branch*. And we *can* have multiple
heads per repository (which is the same monotone and mercurial do --
they don't have a concept of a branch at all, only a checkout and a
repository).

The question becomes what to create the Branch object (which we need for
commit and many other operations) from.

All we need to create a Branch is a revision-id and a repository to
fetch it from (apart from that a BzrBranch has revision-history, which
is just a cache, and a nick, which this "ultralight" branch does not
need).

So my idea is to allow having the working tree in a special state, where
rather than to a branch it would point to a repository. When opening a
branch from such a tree, we'd create this special branch.

To get a working tree into this new state I would propose using switch
to revision.

The same functionality would also allow implementing parametrized URLs.
Basically whenever you'd Branch.open('path;rev=revid'), it'd create this
"ultralight" branch. You could branch, pull, merge, diff, log etc. from
it without need to update those commands at all.

It should probably be read-only in such case (writing would work just
fetching the revisions into the associated repository, but I think it'd
be confusing more than useful in this case) and switch would have to be
special-cased to set the tree to the above state.

>     This is the common established practice in traditional sequential
>     VCSs, in part because in those systems, branching and merging
>     aren't lightweight enough to be worthwhile using for a small fix.
> 
> Any sort of branching that requires explicitly setting up a new branch
> and making the change in it, then moving over to your main branch and
> re-merging, is still pretty heavyweight for that sort of thing.  But
> having multiple heads on one branch, you can easily just flip back to
> the right rev, make the change, then merge the heads[0].
> 
> > 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?
> 
> Several paths.  One path is the git-ish "one working tree, N branches,
> switch between them".  Another is the almost-bzr-ish "N branches in a
> repo, one lightweight checkout, switch between them".  There's a
> slight difference.

Bzr actually supports -- almost -- the same setup as git, though it's
certainly harder to set up. Basically:

repo$ bzr init-repo
repo$ mkdir -p branches/master
repo/branches/master$ bzr init
repo$ mkdir workdir
repo/workdir$ bzr checkout --lightweight ../branches/master

Maybe we could have some special support for collocated repository and
checkout and branches in a special directory (.bzr/refs/branches?), but
I am not sure it's actually such a big win.

> In all my years of using CVS and trying to get other people to use it,
> one of the biggest conceptual stumbling blocks was always getting them
> to understand "this is a _repository_, this is a _checkout_", and why
> they need both.  It took ages for most people to Get It, and after
> they did, most of them still cited it as something they "hated".
> Completely boggled my mind.  Heck, the distinction always seem
> blindingly obvious to me.  And I used RCS which _didn't_ have a
> seperate location for the repository, and talk about "hate"...
> 
> Having used bzr for a while now...  well, I still don't understand why
> it's such a hard concept for people to understand.  But I get how
> annoying it can be.  I still like it in some ways, but I can sure see
> the irritating side of it.  For instance, last night on IRC, walking
> ryanakca through a SVN-style setup, I kept finding myself thinking
> "This is stupid.  Why are we setting up this whole seperate repo over
> there, instead of just having it all in the tree here?"
> 
> There's a lot of simplicity in the git model; all your data is RIGHT
> HERE, just like a bzr standalone branch, except with a working tree
> you can flip to whatever branch you want, including one you create on
> the fly.  OTOH, there's a lot of capability in having independent
> branches with integral working trees sitting next to each other you
> can work with.  I would worry about how the two capabilities would
> interact with each other.  I mean, if you have a "standalone branch"
> with 5 branches at foo/, and you "bzr branch foo bzr", what happens?

If such a case is deemed important, we could try to get some kind of
'standalone repositories' described above, where a repository and a
working tree would be collocated and there would be branches in it,
probably hidden somewhere inside .bzr.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb at ucw.cz>