creating checkouts, bound branches and standalone branches from an existing branch
James Blackwell
jblack at merconline.com
Tue Feb 14 20:23:30 GMT 2006
On Tue, Feb 14, 2006 at 11:55:23AM -0600, John A Meinel wrote:
> > 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.
hard bound branches have always struck me more of an "all on" or "all off"
sort of thing in which I have to make a permanant change for a temporary
problem. If I hop on the plane and commit in a bound branch, I don't want
to make a permanant indication for a temporary situation.
I like your --temp idea below. What do you think about adjusting it to
to the following:
1. automatically enable --temp behaviour after two consecutive failures
2. exponential backoff of push attempts until a successfull push
3. A notice on every commit that X commits are not pushed
> 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 :)
>
> 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.
>
--
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/2c8ff6dc/attachment.pgp
More information about the bazaar
mailing list