basic usage questions

[John A Meinel]

Gábor Farkas wrote:
> hi,

...

> let's describe a simple scenario:
> 2 developers, A and B, one central repository C.
> 
> A checks out a copy of C, and starts to work on a feature.
> B also checks out C, and starts to work on a feature.
> 
> some time later, when the feature is completed, A would like to update C 
> with his changes. how should he do it? should he simply rsync/sftp to C?
> but then, what happens when B wants to update C with his changes? his 
> "update" won't remove A's changes?
> 
> or the workflow is completely different in the case of bzr?
> 
> sorry for the long mail, i just would like to "grasp" this concept, and 
> i still feel that it escapes me...
> 
> i've read http://bazaar.canonical.com/SVNPerspectiveOnBzr, but it did 
> not help unfortunately...
> my problem with that document is that he always talks about "merge from".
> 
> 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. 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

    (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. But this is true for all revision control 
systems. (Think CVS, when you 'cvs update' you actually are running a 
merge of your working tree against the last commit. If you fix up that 
merge, and then go to commit again, someone could have applied an 
update, which you then have to merge, etc)

The only difference with bzr, is that it will let you commit locally, 
even if that commit wouldn't succeed remotely.
Some of the changes we are working on are meant to help inhibit local 
commits when you are out of date, so that you don't have to have a whole 
lot of self discipline (to always run bzr pull and push at appropriate 
times).

John
=:->


> 
> 
> thanks,
> gabor
> 
>