basic usage questions

[Gábor Farkas]

John A Meinel wrote:
> Gábor Farkas wrote:
> 
>> what i don't understand is how "merge to" happens :)
>>
>> or there is no "merge to"? meaning that there's no central repository, 
>> but someone has to kind-of "own" the central repository and "pull" the 
>> other developer's branches changes into it?
> 
> This might be a good way to look at it.
> 
> bzr doesn't let you "merge" to anything but a local directory. 

thanks. this sentence clearead up a lot for me :)

> That is 
> because the contents of files have to be meshed together, which could 
> lead to conflicts which has to be resolved.
> 
> It will let you pull or push changes which have already been committed 
> around. So that in your above scenario you could do:
> 
> bzr branch sftp://server//path/to/C local-A
> bzr branch sftp://server//path/to/C local-B
> 
> cd local-A
> <hack hack>
> bzr commit -m "Added new stuff"
> 
> At this point, user A wants to let people know about these changes, they 
> have 2 possibilities:
> 
> 1) They can create a new remote branch using:
>      bzr push sftp://server//path/to/A
> 
>    This creates a new branch which A can publish their changes to.
>    Now, whenever user A creates a local change, he has to "bzr push"
>    to publish those changes to the remote location. (We are working
>    on implementing things so that it can be automatically done, but
>    that hasn't been completed yet)
> 
> 2) A knows that C is actually meant to be shared, and feels okay pushing
>    new changes directly to the shared branch. As long as nothing new has
>    been pushed to C, this command should work:
>      bzr push sftp://server//path/to/C

ok. i understand..

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"?


> 
>    (And once it has been done once, a simple 'bzr push' will use the
>    last address).
> 
>    If user B hasn't committed any new work, and wants to grab A's
>    changes, he can simply:
>      bzr pull
> 
>    (pull uses the last used location, which was set when you branched)
> 
>    So one way that both A and B can stay up-to-date with central branch
>    is to use this workflow:
> 
>      wake up
>      bzr pull # Grab anything that occurred last night,
>               # not strictly necessary
>      <hack hack, ready for something new>
>      bzr pull # Make sure no updates while I was hacking
>      bzr commit -m "Commit my changes"
>      bzr push # Upload my changes to the remote
> 
>   Now there is a race condition, where someone could push a change
>   to C between the pull and push.
> 
>   But there is a workaround... Merging.
> 
>   If both branch A and branch C have commits that do not exist
>   in each other, you must merge the two branches before push
>   and pull will work again. In general that should be as simple as
> 
>     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?

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

thanks a lot,
gabor