help: shared mainline over ssh

Emanuele Olivetti emanuele at
Sun Aug 9 21:24:22 BST 2009


I need to set up a repository with shared mainline to let the users
commit their changes locally when they are offline and pull/push from
time to time (e.g., once/twice a day) to the mainline to share their
work. I have a server with ssh and can set up accounts for each user
of the repository. I'd like to know if I'm doing right or I missed
some important bits. Note that I'm not following the guidelines of the
user docs in order to set up the solution. That's why I'm asking for

Assume that, on the server, I created an account for each user and
enabled ssh. Then I added all users to the group 'projects'. Then:
# now I'm on my local machine
mkdir myproject
cd myproject
bzr init
bzr push --create-prefix s
ssh emanuele at
# now I'm on to the server...
cd /projects/myproject
chgrp -R projects .      # tweaking permission to grant users write 
chmod -R g+rwxs,o-rwx .  # the sticky bit will ensure same permissions 
for future files created by other users
Then I send an email to each user saying:
Start branching with
bzr branch sftp://<login>
then hack content in myproject/ as agreed and commit frequently.
Then pull
bzr pull sftp://<login>
and push
bzr push sftp://<login>
when you can.
(note that they all push to the same remote directory)

Is this an acceptable solution? In this case users do not need to bind
to make their own repository a checkout and unbind when they are not
online, but the underlying idea is the same. Since my users don't
really need a full fledged personal branch, they work directly on
their local mirror of the central mainline. I know this isn't much
safe when pushing (i.e., there are no gatekeepers) but for small teams
it can be acceptable.

By the way, why am I doing this and not just following precisely the
workflows in the user docs? Because it seems easier to my users to
think in terms of commits vs. push/pull in order to work locally or
synchronize remotely. They understood it promptly.

What are the flaws (real and potential) in this solution? If there
aren't big issues, why this way is not mentioned in the workflows'

Kind Regards,


More information about the bazaar mailing list