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

[Robert Collins]

On Sun, 2006-02-12 at 17:09 -0600, John A Meinel wrote:
> 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').

Hmmm. I think of bzr as a post-distributed RCS these days. We have
support for both centralised and decentralised use cases, but our
*primary* focus is delivering a lovable and effective RCS.

Also 'get' as a verb does not imply 'creation' to me. 'checkout' is a
well known term for 'make a connected-to-the-server working area'. 'get'
is AFAIK arch specific - baz and tla and larch and arx - and is just an
alias to checkout. 

So I object to 'get' making a new branch. Note that a bound branch does
not make a new branch - the workflow policy means that its logically
[and physically while online] the same as the branch its bound too until
the user takes an explicit action.

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

Well, 'switch' is the --overwrite case here IMO. And unlike pull which
resets the branches parent with remember, it would leave the branch
intact and switch the working tree and branch reference only.


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

Other than s/get/branch/ I agree with this.

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

I think we should encourage people to use bound branches rather than
literal checkouts as much as possible [as long as we have the automatic
offline commit support in]

I.e. 'checkout' could make a bound branch, 'checkout
--no-offline-support' could make a literal checkout. Or 'get' could make
a bound branch and we can recommend 'get' in the checkout help.

On the performance side, I figure that when a smart server comes along
we can make checkouts reasonable over high latency low bandwidth links,
but until then its primarily local disk and LANs that will use them.

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/e3f8b65a/attachment.pgp