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

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.