"Co-located branches" by convention

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> 2009/12/1 John Arbash Meinel <john at arbash-meinel.com>:
>> Martin Pool wrote:
>>> 2009/12/1 Ian Clatworthy <ian.clatworthy at canonical.com>:
>>>> Thoughts?
>>> I think it's an interesting way to experiment with it.  I'd certainly
>>> hope that eventually this gets solved in some standard way across
>>> Bazaar not in similar but adhoc ways across explorer, nested trees,
>>> and whatever, but perhaps this is a good way to get there.
>>>
>> personally, I think the previous "shared tree" approach was much more
>> powerful. Yes, I'm used to the model. But I frequently share branches
>> between two "active" working trees.
> 
> So I guess it depends a bit on the scope of the feature or of this
> conversation.  If Ian's finding this useful within explorer I don't
> object to it, and perhaps experimenting with that is the best way
> forward.

Sure. I was mostly offering my counterpoint to the conversation. Putting
the repo and branches underneath the WT has some interesting properties.
I wanted to point out some of the nice properties about having the
branches separate from the WT.

Note that one issue Barry Warsaw pointed out for having the branches
share a namespace, is that he feels it 'clutters' things when he wants
to work with pipes, etc. (He may want to re-use short-names, etc.) Since
Launchpad only allows a flat namespace (~user/project/branch) this is
probably an issue anyway.


> 
> I think ideally we would get to a single setup that worked adequately
> for everyone but that scaled from simpler to more advanced uses, to
> avoid the confusion identified in the case of emacs (and others) that
> people can recommend several different ways to use the tool - not
> technically incompatible, but likely to confuse new users.
> 
> You could name a set of use cases for foreign branches, and perhaps
> before deciding one approach is the best solution overall it ought to
> be checked against that set
> 
>  * pushing/pulling multiple related branches from one place to another
>  * having short names for other branches so they can be used for log, merge, etc
>  * mapping foreign systems that support multiple sub-branches, primarily git
>  * tracking the branches used by nested trees or by looms or pipelines
>  * distinguishing mirrors of other upstream branches vs your own branches
>  * ...
> 
> I think implementing this, at least in the first cut, by composing
> BzrBranch objects is fine.  It would be good to at least get the api
> abstracted eventually so that it could be handled by foreign control
> directories, and so that it can migrate to something possibly smaller
> than full BzrBranch directories eventually.
> 

I don't know that other systems have the 'best' layout, but certainly
being able to support their model is something we would like to do.
Arguably, there are other ways to do what I want. Which is:

1) Be able to work on a feature branch (#1)
2) Commit it, push it up, submit it for review.
3) Start working on another feature branch (#2)
4) While that is in progress, respond to review commentary about #1.
   Note that often I have uncommitted work that isn't quite ready for
   commit, but I want to switch to working on #1.

Right now, I do most work in my "work" checkout. I then push that up for
review. If I get review feedback before I'm ready to "bzr switch", then
I just go to "alt_work" and bzr switch to the #1 branch.

Being able to have 2 working trees pointing at the same group of
branches allows me to not have to worry about whether I need to commit,
or shelve, or (etc) my pending work. Update the old stuff, and then
switch back.

I can also imagine something like this working fairly well with
pipelines or looms, etc. There are reasons to shelve/switch/commit/etc.
It also can be nice to just work in another checkout.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksUAZ0ACgkQJdeBCYSNAAM+7gCfW6Vyk2uIXxfmsYIpufSlt5XW
ImoAn0HVzmSXqU+dV3n1ULwtlNqpGy+o
=deJU
-----END PGP SIGNATURE-----