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

[John A Meinel]

Jari Aalto wrote:
> Robert Collins <robertc at robertcollins.net> writes:
> 
>> On Tue, 2006-02-14 at 11:55 -0600, John A Meinel wrote:
>> 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.
> 
> For me this sounds like quite natural workflow.
> 
>     ( local repository )   <= MASTER REPOSITORY
>       |
>       |
>       Work, edit, check in to local (offline that is)
> 
>     ...
> 
>       Hm, I probably need to sync from MASTER to not to be left behind
> 
>       $ bzr sync --type=pull         # or whatever option
> 
>       some conflicts, resolve those and continue local edit
> 
>     ...                    
> 
>       I'm finished. Compiles good, all looks nice. commit to MASTER
> 
>       $ bzr sync --type=push         # or whatever option
> 
> Or something like that. When I gain experience I may be able to
> "isolate" the local change to separate local branches and then commit
> those that have been finished to MASTER one by one (according to added
> features).
> 
> Jari

Do you realize that we have all of this. Explicitly...

#Get a local branch:
bzr branch master local
#Commit locally
bzr commit
bzr commit
bzr commit
# Must be up-to-date with master
bzr merge
# Push to master
bzr push

We have local versus master commits. It is called 'push'. It is
explicit, and seems to satisfy all of the requests of Robert. You can
commit offline, and you can push to the master when you are done.

Personally, I *don't* want this. What I truly honestly want, is for my
changes to be pushed to my published repository sometime very soon after
I have committed them. Then I don't suffer the delay at commit time, and
I don't have to remember to 'push'.
In Arch I had the opposite problem, that it wouldn't update the local
cache after committing remotely (baz fixed this in 1.5), so I created an
after commit hook that forked off an 'update local' command.

The problem with pushing after commit is that you can get out of sync.
And how are you told that (the other process is forked off). If we had a
gui you could pop up a dialog box. Otherwise we could send an email.
All this will ultimately happen with a plugin.

Anyway....

In my head, Robert's dual-phase commits are already supported.
Bound branches are about something else.

I'm not 100% against Robert's idea, and if people are aliasing "'bzr
commit'='bzr unbind --temp || bzr commit'" then obviously we are doing
something wrong, I agree.

Robert is very strong in his opinion, and I am less so. So while I
disagree, I'll bend to keep from having to argue about it all the time.

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