basic usage questions

[David Allouche]

On Wed, 2005-12-07 at 00:28 +0100, Gábor Farkas wrote:
> but... are these "bzr push" commands "plain" copy-to-remote-host 
> operations only? or is there some kind of locking involved?
> for example what if B decides to branch C while i am pushing my local 
> changes to C? will he get a mixed-up/broken copy, where some files are 
> "new" and some files are "old"?

"bzr push" does essentially three things:

     1. check that the target (remote) branch does not have new history
        not present in the source (local) branch
     2. add new revisions from the source branch to the store of the
        target branch
     3. atomically update the history of the target branch to be up to
        date with the source branch

A pull (or checkout, or merge) happening concurrently to a push should
never cause incorrect state to be retrieved because:

      * push ignores the checkout associated to the target branch, that
        means it does not update the source files, only the store and
        history.
      * Pushed store data is not significant until the history is
        updated.

Also, checking the log of Martin's bzr branch, you can see:

    merged: john at arbash-meinel.com-20051105083701-efc57f6197d8b137
    committer: John Arbash Meinel <john at arbash-meinel.com>
    timestamp: Sat 2005-11-05 03:37:01 -0500
    message:
      Added a form of locking to sftp branches. Refactored
_sftp_open_exclusive
to take a relative path
    ------------------------------------------------------------
    merged: john at arbash-meinel.com-20051105075016-c11d132cd87c5a6a
    committer: John Arbash Meinel <john at arbash-meinel.com>
    timestamp: Sat 2005-11-05 02:50:16 -0500
    message:
      Adding a open_exclusive function since paramiko supports it, but
doesn't expose it

Which means bzr now does support locking on sftp to prevent concurrent
pushes from breaking havoc.

All this atomicity and locking does not apply when using the rsync form
of push, which is ugly hack but a useful performance optimisation when
pushing to a branch that is owned by a single person.

Also, note that you can force push to succeed when the source branch is
not up to date with the target branch by using "--overwrite". You cannot
prevent users with "push" access from using "push --overwrite", but that
can be addressed by policy.

If you wish some of your project policy to be automatically enforced
(preventing push --overwrite, only publishing code that passes the test
suite, etc.) you can use PQM.

http://bazaar.canonical.com/BzrUsefulTools?highlight=%28pqm%29

> >     bzr merge
> >     < check that the changes are reasonable >
> >     bzr commit -m "[merge] Missing some patches from C"
> >     bzr push
> >     # At this point, because all the revisions in C should
> >     # exist in A, a push should succeed.
> > 
> > Naturally, there is still a race condition in this last workflow, where 
> > between the time you merge, and the time you push, someone else has 
> > pushed yet another change. 
> 
> as i mentioned before: what happens then?
> 
> will the push succeed? (i hope no)
> or will he end with an error saying that someone already pushed 
> something else there?

There will be an error. Unless "push --overwrite" is used.

> > The only difference with bzr, is that it will let you commit locally, 
> > even if that commit wouldn't succeed remotely.
> 
> that is ok for me. my local commits are my local commits, where i do 
> whatever i want, but my "remote commits" are something different.
> 
> thanks for the comments, i think i understand this now better.
> 
> hmm... maybe it would be good idea to write parts of the documentation 
> as example scenarios... about how bzr solves given situations...

You are more than welcome to contribute documentation on
bazaar.canonical.com. You may consider that a form of payment for the
user support you received :)

-- 
                                                            -- ddaa
-------------- 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/20051207/7a989ab0/attachment.pgp