Empty directories where branches are, and how to work centrally (was Re: questions from a new bzr user)
rdiaz02 at gmail.com
Fri May 5 02:23:14 BST 2006
Thanks a lot for your detailed and prompt answers. They certainly
solve both of my questions.
Ooops, now I realize that the answer to the first question is implicit
in the checkout tutorial (which I thought I had read ---I guess its
getting too late here). Would it be worth to include this as an entry
in the bzr web page?
Thanks again for your answers.
On 5/5/06, Robert Collins <robertc at robertcollins.net> wrote:
> On Fri, 2006-05-05 at 02:48 +0200, Ramon Diaz-Uriarte wrote:
> > 1. I have a "central repository" in a server, and then do my work on,
> > say, a laptop. Other colleagues might be doing the same. Now, I'd like
> > to store my changes in the server. As my colleagues might have been
> > editing the same files, I use merge, not push. However, to use merge I
> > need to log into the server, and do a merge from there. Is there a way
> > to do the merge (going from my laptop to the server) issuing the
> > command from my laptop?
> > 2. I cannot find post 0.7 releases of bzrtools as the link from the
> > plugins page takes me to an empty directory. Either the sources or a
> > deb would be fine. I found the deb package, but it depends on an
> > ubuntu package; I can force installation, and it seems to work, but I
> > don't like it. Are there places/repositories I am missing?
> > Actually, being directed to empty repositories has happend with some
> > other plugins. And for bzrk I was taken to files from late 2005
> > (though for this I saw the deb package).
> Answering in reverse order because its easier :). The 'empty'
> directories are probably bzr branches: if you do 'bzr branch URL' you
> should get a full copy of the code. (You can just add .bzr to the URL in
> your web browser to test this). The reason for this is that pushing the
> unpacked source code around for a branch takes a long time - we can't
> quickly determine if a remote file has changed, and wouldn't want to
> overwrite a file without merging... So we decided that we would not
> write the unpacked source code when pushing over FTP or SFTP. The recent
> addition of 'knits' to bzr has made our built in 'push' fast enough that
> people are no longer using the 'rsync' style push, but have switched to
> using a 'shared repository' to publish their branches.
> For the centralised workflow we have added an optional feature that
> provides built in support for shared branches.
> Lets assume you have your shared branch at
> If you perform a *checkout* of this branch to your local machine, bzr
> will understand that this is a shared branch, and let you know when
> other people have done edits, and allow you to reconcile them locally.
> Here is one way you can use this:
> # Create a checkout of the shared branch
> $ bzr checkout sftp://example/org/srv/bzr/yourbranch shared-branch
> # Create a branch I'm going to work on
> $ bzr branch shared-branch feature-X
> # do some work in feature-X
> $ cd feature-X
> $ touch foo
> $ bzr add
> $ bzr commit -m 'Add foo'
> # new we do a merge and publish it in the shared branch
> $ cd ../shared-branch
> # pickup any new work in the shared repository
> $ bzr update
> # now merge the changes you did in feature-X
> $ bzr merge ../feature-X
> # and commit them (after resolving any conflicts)
> $ bzr commit -m 'Merge in feature-X'.
> That last commit will commit directly to
> sftp://example/org/srv/bzr/yourbranch and is multi-user safe. If another
> user has committed before you did, you can just do a 'bzr update' and
> then do the commit again.
> Hope this helps,
> GPG key available at: <http://www.robertcollins.net/keys.txt>.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v220.127.116.11 (GNU/Linux)
> -----END PGP SIGNATURE-----
Spanish National Cancer Centre (CNIO)
More information about the bazaar