How to organize a 'central repository'
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!
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