creating checkouts, bound branches and standalone branches from an existing branch
John A Meinel
john at arbash-meinel.com
Tue Feb 14 17:55:23 GMT 2006
James Blackwell wrote:
...
>> 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.
>
...
>> 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.
This is the source of some disagreement within the group. At UBZ, Robert
wanted a bound branch to go offline automatically, so that you can
commit, but when you come back online, it should refuse to commit if you
are out of date.
I dislike the idea of it going offline behind my back, but I do like the
idea of it automatically coming back online when the other branch is
available.
I would consider using "bzr unbind --temp" to indicate that I am okay if
the branch is offline right now, but still try to see if you can
automatically rebind later.
This may be an option we don't need. I do understand Robert's idea. But
in my mental model, I would know that "this is a bound branch, I don't
have to do anything for my changes to be published". And then if I
'unbind' it forces me to think that they won't be published until it
rebinds. And it sort of reminds me that when I land, I need to 'bzr
bind' again. (even for branches that auto-rebind you have to issue a
command like bind/commit for it to go out and check, unless we want to
run a daemon that automatically checks :)
>
> 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.
I think the user needs to be aware that their changes aren't being
published, rather than quietly changing their branch. (we might print a
message, but that won't always be read, interrupting a command is more
explicit).
I think a clear statement of "I cannot commit to the bound parent
because of X. See 'bzr unbind'". Would be better than doing it for them.
I'm not stuck on it, but I want to make sure the user knows what's going
on. Even if we try and be very kind and do as much as we can for them.
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/20060214/481f91cc/attachment.pgp
More information about the bazaar
mailing list