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

[John A Meinel]

Robert Collins wrote:
> On Sat, 2006-02-11 at 23:42 +0100, Denys Duchier wrote:

...

> 
> 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). 
> 

Since bzr is defined as a distributed rcs, I think we should keep that
behavior (create a local standalone (or local repo) branch is the
default result of 'get').

>> 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.

I agree on both points.

> 
> 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.

Yep.

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

Actually, pull --overwrite --remember, but see my earlier statement that
pull should probably default to --remember because of the new
convergence rules.


> 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 do have to agree that a lot of people just get the latest CVS snapshot
because they want to install it, not because they want to hack on it.
But if we have "bzr checkout" do that and "bzr get" give us a full local
branch, I think we have those 2 use cases covered.

> 
> 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
> 

I would just change "bzr branch" to "bzr get" in the first help. But I'm
not stuck on it. (I'm still concerned about how fast something like 'bzr
status' or 'bzr commit' is going to be with checkouts, since there is a
kind of underlying assumption that data is local).


John
=:->


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