Penny has described what we do quite well. Earlier, I had written a description of the alternatives -- but moodle.org seemed to be down so I sent it to Gustav directly.
So, for completeness sake, here it is:
There are three techniques you can use, depending on the size of the team, and the relationship you have with the main SCM repo (in this case, Moodle CVS).
Firstly, you can use shared sandboxes (over NFS or SMB). This is tricky and requires a lot of coordination.
Using per-developer sandboxes, the simplest one is to use the upstream repository (moodle CVS). This clearly doesn't scale, and makes the repo owner uncomfortable, but for teams of two or three working on separate modules or parts of the code, it is "good enough".
To minimize the impact if you are developing fast and furious, and don't want to break the tree, you can work in branches. But, again, this can make Martin Dougiamas rather uncomfortable.
The third alternative is to run a local SCM repository. CVS supports you running a "local branch" using the functionality known as "vendor branch" (see the vendor branch techniques described in http://cvsbook.red-bean.com/
). We have used CVS with moderate success to run a local development branch of gForge.
The problem is, CVS sucks at merges. Not at single merges, but in any scenario with multiple and frequent merges, CVS will drive you to suicide. And having a local repository tracking an upstream requires merging a lot of code, very often. Dealing with CVS on the gforge development took a lot of work.
Arch is an alternative SCM. Using the techniques described in
we are running a "local" Arch repo of Moodle. We develop fast and furiously there, committing early and often, and then we lump a batch of related patches and commit it to CVS.
When we re-merge from upstream, we tell Arch that the upstream
"contains" those patches already, and Arch won't flag them as conflicts. (CVS ain't that smart).
Still, a lot of the integration and merging requires manual procedures. If moodle was using Arch, all this would be much simpler. But for Arch to be a compelling choice for Moodle development, it will take some time.
Using either solution, you will be merging and remerging quite a bit. So conflict resolution is something you need to do with care. Arch helps a bit mor than CVS, but conflict resolution is _hard_. Good SCM systems help, but the core of the problem is hard.
In fact, one of the most useful tidbits we've found was the Emacs trick Penny refers to, and the 'wiggle' utility.