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

Jan Hudec bulb at ucw.cz
Wed Feb 15 07:42:07 GMT 2006


On Wed, Feb 15, 2006 at 18:08:32 +1100, Robert Collins wrote:
> 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.

I like the 'local/full' approach better. I think it's better to be
explicit in this. Besides it might be useful to pretend you are offline
when you are not. And waiting for the remote access to time-out may not
be pleasant either.

Perhaps there would be a --local (-L) option, that would make the branch
behave as unbound for one operation. (All operations that are affected
by bound branches should have it. Are there any other than comit?)

> 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

IMHO there should be a merge --swap-parents to do that. Or maybe update
on unbound branch would do that (it's a straigthforward generalization
of what it does on a bound one, after all). Because often you want to do
that even with an unbound 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.

Yes, that's nice.

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

Would become:

commit -L
commit -L
update
commit --no-local [to make sure it connects, if auto-local enabled]
commit
commit -L [in the plane again]

Is that less horrible UI-wise?

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

Maybe it could always work with -L and user option would control whether
that option is implied when access to the parent fails. We would need
to allow negating the option -- --no-local to disable auto-local if
turned on.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- 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/20060215/7c2705ae/attachment.pgp 


More information about the bazaar mailing list