How to organize a 'central repository'

Peter Arrenbrecht peter.arrenbrecht at
Mon Mar 31 01:16:30 CDT 2008

On Mon, Mar 31, 2008 at 2:07 AM, Brian Wallis
<brian.wallis at> wrote:
>  The next step is to work out how Mercurial is going to be organized
>  for our project and I am thinking about what repositories I need on
>  my build server (which will have the definitive repo for builds and
>  is regularly backed up).
>  I'm thinking of the following.
>  - A repository containing all the branches and from which builds are
>  done. This would be the definitive source. Developers would clone a
>  branch from here to do work and would push completed/tested changes
>  back to here after merging on their own machines. Our hudson build
>  server would clone/update from here for builds.
>  - A second repository containing developer branches. This is where
>  developers push incomplete/untested changes and experimental work.
>  The main reason for this is that it is backed up whereas developer
>  machines are not. It is also a central point where developers can
>  share work without affecting the production building and testing.
>  I have a couple of questions,
>  1) Should I use multiple repositories for the main development
>  branches instead of just one? (it does seem to use a lot more
>  diskspace this way).

If your file system supports hardlinks (which most do), it won't. Hg
shares history between local clones using hardlinks. And server repos
don't need working copies at all, so all you care about is history
storage. You might want to run a relink script from time to time,
though (

Personally, I would recommend using separate repos. Named branches are
still an unpolished feature (from what I read on the list), while
using separate repos is straightforward. (But you may want to wait for
other reactions here.)

>  2) Would I need a cron job to pull changes from the main repo to the
>  second one to keep the second repository in sync with the main one?
>  Or would this just happen as a consequence of developers pushing in
>  their own branches (I suspect it would).

No need. But again, I even more strongly suggest you not mix developer
branches in a single repo. Have a dedicated repo for each developer,
or even more than one. And maybe your developers are even going to
want to use mq, which will mean server-side mq repos instead of base
repos, which aren't even clones of one another.


More information about the Mercurial mailing list