help: shared mainline over ssh
emanuele at relativita.com
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
bzr push --create-prefix sftp://firstname.lastname@example.org/projects/myproject
ssh emanuele at my.server.com
# now I'm on to the server...
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>@my.server.com/projects/myproject
then hack content in myproject/ as agreed and commit frequently.
bzr pull sftp://<login>@my.server.com/projects/myproject
bzr push sftp://<login>@my.server.com/projects/myproject
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'
More information about the bazaar