"Co-located branches" by convention

[Ian Clatworthy]

Over the weekend, I did some work on making Explorer's 'shared-tree'
more useful. To give some background for the cli die-hards, the Init
dialog in Explorer offers 3 ways to init a branch. The "workspace model"
users choose between are:

* Feature branches
* Shared tree
* Plain branch

The first creates this:

xxx/       (shared repo)
  trunk/   (branch)

The second creates this:

xxx/      (treeless shared repo)
  trunk/  (branch)
  work/   (lw checkout pointing to trunk)

The third creates this:

xxx/      (branch)

My weekend Explorer patch changes #2 to create this instead:

xxx/             (lw checkout pointing to trunk)
  .bzrbranches/  (treeless shared repo)[1]
    trunk/       (branch)

That's nice because it makes it easier to put something under VC in a
model more useful than 'plain branch': there's no need to move existing
content out of xxx into either xxx/trunk or xxx/work.

Together with some UI tweaks where opening xxx/.bzrbranches gives the
page a title of xxx, Explorer with this patch is getting close to the
point where 'shared-tree' is almost as easy-to-use as
'features-branches'. (Not quite, but I can imagine starting to use it
much more often than I do now, particularly if the Branch dialog offered
the workspace models and not just Init.)

So, what does this mean to the cli crowd? It can easily mean nothing
because they'll never use Explorer. :-) OTOH, maybe it's food for
thought about whether the cli users could also implement a poor man's
"colocated branches by convention". For example:

1. Someone in the community could take the (hidden) "init-ala-explorer"
   command in bzr-explorer and use it as a basis for a more powerful,
   standard init command (think new options called --feature-branches
   and --shared-tree).

2. Someone could purpose a shorthand syntax for referring to
   ".bzrbranches", e.g. project/:/branch[2] instead of
   project/.bzrbranches/branch. It's a non-issue for GUI users
   because we tend to just use the Browse button anyway to select dirs
   but it may make the cli nicer for those using a 'shared-tree' from
   the cli.

Two more comments:

3. Yes, using .bzrbranches isn't the same thing as true colocated
   branches, ones that bzr-git can use for referring to git branches.
   (Then again, /:/branch seems as good-or-bad as any URL syntax
   proposal I've seen and we seem incapable of agreeing on a scheme.)

4. To me personally, doing collocated branches "properly" is a big
   job and lower on my list than stuff like branch-specific rules and
   nested trees. OTOH, a simple "by convention" approach may gives our
   users a good enough solution now, rather than waiting for a better
   solution later. *If* there's consensus this is interesting and
   some community folk run with patches for 1 and 2, it's worth doing
   IMO.

Thoughts?

Ian C.

[1] I'm not hung-up on .bzrbranches as the name. It's readable in
directory selection dialogs in the GUI but .bzrrepo (say) would be fine
as well. Or whatever. I have a preference for a single level though over
.bzr/branches though.

[1] Another more general solution might be to move
https://launchpad.net/~marienz/+junk/repoalias into the core and support
aliases in URLs, e.g. project/repo:/branch, branch/push:.