DVCS working on remote server

Question

My workplace is considering moving to a modern (D)VCS which is something that I am pushing for.

My boss is in on the idea and the current workflow would be to have a centralized repository where everyone can commit/merge their changes when a task is done, While working on a task each developer can have their own branch to work on and commit to.

The problem is that he is not very fond of the idea that people have code on their workstations only until the changes are pushed into the shared repository. This is because of disk failures and so on.

What he would like to see is that everyone had their own branch on the server which would automatically be updated when you commit on your local workstation.

Does any DVCS support this in an easy to setup way?

Note though that I personally think it is perfectly acceptable for each developer to take responsibility of backing up their code by for example simply pushing their changes to a private branch on the remote server. This could be done manually or automatically with a cron script.

Answer 1

You can prepare a post-commit hook (see .git/hooks/post-commit.sample in your local repository) to automatically push the current branch to the server.

If you do this, I think the branch names on the shared server should be prefixed with developer's name to prevent name conflicts.

Answer 2

This sounds fairly similar to the set-up that we have with Bazaar at the moment, but I think it can be replicated in Mercurial and others using post-commit hooks in Git or "push-after-commit" in Mercurial. The way of doing this in Bazaar would be to do something like this:

# Create a repository
bzr init-repo --no-trees path/to/server/project
# Create the main development branch
bzr init path/to/server/project/trunk
# Create the local working copy (which contains the complete history but is bound to the server copy of trunk)
bzr co path/to/server/project/trunk working-directory-name
# Alternative command that works the same:
bzr branch --bind path/to/server/project/trunk working-directory-name

cd working-directory-name

# Now create a branch for the user to work on
bzr switch -b new-branch
# Hack hack hack
# Commit (gets pushed to server as this is a checkout a.k.a bound-branch)
bzr ci -m "Done stuff"
# Go back to trunk to merge
bzr switch trunk
# Merge
bzr merge path/to/server/project/new-branch
# Commit the merge changes (gets pushed to server)
bzr ci -m "Merged new-branch"

All the branches will be held in a repository at /path/to/server/project. Any commits to the local working copy will be pushed to the server automatically. If you use GUIs, you can install my remote-feature-branches plugin, which automates the process of creating a new repository with a trunk branch and checking it out locally (the first three commands above).

---

I've only used Mercurial a little, but I believe that the way you'd do this would be to have a branch on the server and to branch it locally and edit the .hgrc file to include:

[hooks]
commit.autopush = hg push

All users would have a local copy that contains all branches in this case, whereas in Bazaar, the local copy would only have the history of the branch that they were working on. Slightly different implementations, but functionally much the same I think.

Answer 3

Just for the "us too" factor: this is doable in mercurial as it is in bzr and git. Just use a commit hook that pushes to a more central-ish repo when available. Something like this:

[hooks]
commit = hg push ssh://path/to/individual/developer/repo

One thing I'll note is that rather that enforcing this via hooks you can make pushing to central repo attractive to individual developers and you'll find they do it on their own. Things I've done to get people committing/pushing (daily/hourly):

• make sure they have a repo they can push to that has no expectations about compiling/tests passing - a checkpoint repo if you will
• make it easy for them to set up a continuous integration build of repos of their choice on the central server -- if it's three-clicks-easy for them to start build-on-change for their personal branches then they'll be pushing after each change just to see the test suite run
• don't shame them for having a branchy history -- good DVCS use involves a lot of pull/merge/push cycles. If you make them use rebase or collapse to turn 30 changesets with 15 merges into one changeset per feature/bug then they're incentivized to keep thing local until they're ready to pull/merge/push the whole thing at once
• run some non-judgemental metrics in a public place. Nothing draconian and silly like ranking developers by lines of code, but something that can be noticed, whether it's an aggregate RSS feed from all the repo RSS feeds, or a commits@ email alias that gets a quick "X pushed changeset Y into repo Z" message whenever someone pushes. That's nice because people always like a little sunshine on their extra-hours-worked and a "push" at the end of session gets that.

Answer 4

Hi,

Looks like your boss is working for the ability to have a DVCS but also wants to have a centralized SCM while working "at the office".

It that's correct, then why don't you take a look at Plastic SCM? That's exactly what we do: you can go distributed or (more "enterprise friendly") you can work centralized (or a combination of the two. And still it is all about branching.

Take a look at these two articles:

http://codicesoftware.blogspot.com/2010/08/branch-per-task-workflow-explained.html http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

And maybe here too: http://www.plasticscm.com/features/task-driven-development.aspx