How to organize a 'central repository'

Brian Wallis brian.wallis at infomedix.com.au
Sun Mar 30 19:07:17 CDT 2008


After much experimentation I have a successful conversion of our 6  
year old (and very messy) CVS repository (using Tailor and cvs, not  
cvsps). I'm only converting part of it (head and two active branches)  
and only the history since 1/1/2007.

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).

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).

3) Any other comments/suggestions would be most appreciated!

thanks,

Brian Wallis
InfoMedix
p: 3 8615 4553 | f: 3 8615 4501 | e: brian.wallis at infomedix.com.au
Level 5, 451 Little Bourke Street, Melbourne VIC 3000





More information about the Mercurial mailing list