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

[James Blackwell]

On Tue, Feb 14, 2006 at 02:50:32PM +0100, Erik Bågfors wrote:
> 2006/2/14, James Blackwell <jblack at merconline.com>:
> > On Sat, Feb 11, 2006 at 11:42:41PM +0100, Denys Duchier wrote:
> >
> > > [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.]
> >
> > (technically, "get" is an alias for "branch". Your point does come through
> > though)
> >
> > > I would propose that:
> > >
> > >       bzr get --commit=remote       URL PATH
> > >         bzr get --commit=local,remote URL PATH
> > >         bzr get --commit=local        URL PATH
> >
> > I propose the following:
> > ------------------------
> >  bzr branch                   |  Defaults to branch --lightly-bound.
> >
> >  bzr branch [-c|--checkout]   |  A checkout.
> 
> But,,,,,,
> 
> here you are not creating a branch, why should we use the branch
> command.  Isn't that confusing to users? If it was all called "get"
> then I'd be fine with it either being a branch of a checkout. But not
> if it's called branch.

This is true, that a checkout is not a branch.

I have a belief that the concept of "this is a branch; that is a checkout"
will be insubtantial to the day to day behaviours of a feature. Users get
working trees in two or three different ways. Users run commit while in
these working trees. Thats a bit more tangible, and they'll probably be
sloppy and call both of them branches anyways.

>>  bzr branch [-u|--unbound] |unbound branch (with or w/o repo)
>>                            |
>>  bzr branch [-b|--bound]   |a fully bound branch. No remote access,
>>                            |no commit. Probably a bit rare
>>                            |
>>  bzr branch --lightly-bound|a lightly bound branch that breaks binding on
>>                            |on commit if the remote branch is
>>                            |uncommittable*
>>
>>  * I can't decide whether this should be a lightly bound branch. One idea
>>    that appeals to me is the idea of a branch that decides whether its
>>    bound or not based upon the results of the first commit. If the first
>>    commit succeeds, then its fully bound. If the first commit fails, then
>>    its unbound.
> 
> I'm not 100% sure about this one either as I think it can cause
> confusion.  I did this, and sometimes what I do is propagated up, and
> sometimes not.

I kind of agree and mostly disagree. Yes, its true that the behaviour
would not be consistant across branches. No, its not true that the
behaviour would be consistant in the same branch. 

I think we have lightly-bound branches in the model already anyways. There
are use cases for a branch that is normally bound, that becomes unbound if
a commit can not be sent to the bound-to branch.

The annotation is just a bit of loose thought. If one binds to a branch
and on the very first commit can not write to the branch bound to (because
of lack of write permissions, not because of 404s and transient errors)...
Well, the changes are more than even that the user will never be able to
write the branch.

> > With the following aliases:
> > ---------------------------
> >  checkout & co                | alias for "branch --checkout"
> >  get, clone                   | alias for branch
> >
> >
> > With consideration given to:
> > --------------------------------
> >  bzr rebranch [same options as | Converts a branch from one type to
> >                above]          | another, provided the result is possible
> >                                  and sane.
> 
> That would be really nice.
> 
> /Erik

-- 
My home page:   <a href="http://jblack.linuxguru.net">James Blackwell</a>
Gnupg 06357400  F-print AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060214/864f9839/attachment.pgp