creating checkouts, bound branches and standalone branches from an existing branch

[Robert Collins]

On Sat, 2006-02-11 at 23:42 +0100, Denys Duchier wrote:
> Robert Collins <robertc at robertcollins.net> writes:
> 
> > I can get some code in front of me to hack and commit on in three way:
> >  * Create a checkout
> >  * Create a bound branch
> >  * create a standalone branch
> >
> > The first one [...] clearly has to be 'bzr checkout URL [PATH]'.
> >
> > The third one [...] 'bzr branch URL PATH'
> >
> > But what about the bound branch case? Should that be 'get' ? or 'bzr
> > branch --bind' ?
> 
> How about inverting the question and trying it from joe random's perspective, a
> user who has no particular interest in VCS nor in the underlying concepts that
> are important to us (as designers and implementers).
> 
> It seems to me that, from a user's perspective, the most important thing is to
> obtain a copy of some project so that they can use it and modify it.
> 
> [in the following, I am deliberately using the command "get" rather than
> "branch" or "checkout" to avoid confusion with existing/proposed concepts and/or
> commands.]

This is roughly use case based design, and for that its very helpful to
have specific use cases.

> I would propose that:
> 
> 	bzr get URL PATH
> 
> produce a working tree (checkout) that is lightly bound to the branch at URL.
> This is exactly the centralized model.  It is unsurprising.

It is unfortunate perhaps that it is extremely surprising to users of
bk, hg, monotone, codeville and RCS. (suprisingly enough RCS with its
'vcs data is in the working tree' behaves essentially like a distributed
system, just without good merging). 

> For more advanced users, a secondary issue is how their copy is related to the
> original.  For example, we could have:
> 
> 	bzr get --mirror URL PATH
>         bzr get --copy   URL PATH
> 
> where --mirror would produce a bound branch, while --copy would produce a
> standalone branch.  I just made up these options and probably better ones could
> be proposed.
> 
> The point is that the primary effect of "bzr get" is to obtain a working tree of
> the project at URL.  The option determines in particular what happens when the
> user commits.  This could also be done as follows:
> 
> 	bzr get --commit=remote       URL PATH
>         bzr get --commit=local,remote URL PATH
>         bzr get --commit=local        URL PATH


I've spoken with some users, and they say that often they will want to
start with a 'checkout' and turn it into a 'new branch' later. The scare
quotes are for the specific terms there which are not exactly mapped to
bzr yet.

So I think we definately need to support:
 * making a new branch of the branch a checkout points at and
reparenting the checkout. 
 * making a new branch of the branch a bound branch points at and
reparenting the bound branch.

That addresses the 'well I've changed my mind and want to switch from a
shared branch to a branch of my own, kthnxbye' use cases.

The reverse use case ('switch') is possibly less important, but worth
considering at some point. At the moment users emulate this via pull
--overwrite.

As for commands that give you code in front of you, I strongly believe
there are two primary use cases:
 * Get the code for an existing line of development
 * Make a new line of development

Its common that you will start with the former and decide you want the
latter later. But its incredibly convenient to allow direct access to
the latter use case. And its seriously different in intent, so I think
exposing it as a straight forward command will make it easier to find.


I'm thinking about the help here:

Basic commands:

  bzr init           makes this directory a versioned branch
  bzr branch         make a new branch from an existing branch
  bzr checkout       start working on an existing branch


vs

Basic commands:

  bzr init           makes this directory a versioned branch
  bzr get            retrieve the source code for a branch and
optionally start a new branch at the same time.


I can't find a short summary that encompasses both primary goals. And if
it doesn't, it will be undiscoverable by users.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060213/9a978020/attachment.pgp