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

Robert Collins robertc at robertcollins.net
Wed Feb 15 07:08:32 GMT 2006


On Tue, 2006-02-14 at 11:55 -0600, John A Meinel wrote:


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

I think there is a *huge* semantic gap between 'unbound' and 'offline'.
I'm happy to have the behaviour I was as an explicit option to turn it
on... I'm positive that the response will be considerably in favour of
it once people try it.

I consider bound branches to be a single large branch many people are
working on. Commits to it go into the 'history' and other people cannot
commit when they are out of date. If you examine what users of
centralised systems do, they treat checkouts like small branches. They
edit & edit & edit until they are happy and then they commit.

Bound branches can be *either* a performance optimisation, *or* an
improvement to the work flow. If they are solely a performance
optimisation, then IMO they should have no offline mode at all. They
should completely refuse to operate when offline (because they cannot
represent the actual state of the remote branch without connecting). So
they become 'just' a fat checkout.

If we allow them to be an improvement to the workflow, then *some*
offline operations become possible, and I think its a matter of degree
how far you take this.

My proposal boils down to allowing commits to become part of the natural
workflow.

Another possible way of doing it is having a 'local' commit and a 'full'
commit, a-la bitkeepers 2-phase approach to sharing the code. A 'local'
commit, like the 'edit & edit & edit' sequence above would not push the
code into the main repository, and would be possible without updating to
the tip of the shared branch. When you attempt a full commit though you
have to be fully up to date, and the commit will be applied to the
shared branch. If we do this, then I would want the 'full' commit to
never automatically fallback to a local one, because we would have made
the workflow explicit.

The crucial points both approachs I favour (automatic offline, and local
vs full commits) are that :
 * people dont need to juggle branches around to get the correct 'left
most parent' when committing to the mainline, and when updating along
the shared branch
 * people can commit in some fashion without changing the semantic
behaviour of the branch (that is whether it considers itself a shared
branch or a branch of its own), and without needing to manually toggle
something on and off.
 * The user does not have to create a new branch for whatever they are
doing using this interface. Cases where I imagine this being of
considerable use are 'quick hacks', 'shared mainlines', and non-code
controlled things (i.e. the distro 'seeds' that Ubuntu developers use to
control what goes in the distro).
 * The performance aspects of this become irrelevant to the user.

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

And leads to features being either ignored, or muscle memory forming.
For instance, if the sequence is 
'unbind --temp' [btw thats horrible uiwise]
'commit'
'commit'
auto-online
'commit'
'commit'
'unbind --temp' [back in the plane]

I can well imagine people doing
alias 'bzr commit'='bzr unbind --temp || bzr commit'

remember 'tla create-version -S' ?

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

I agree with that, I dont agree with stopping the command unless its an
irrevocable step. And even commit isn't for us.



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/20060215/5d1dabd2/attachment.pgp 


More information about the bazaar mailing list