I use Mercurial to develop FsCheck, a unit testing framework hosted in codeplex. I am currently the only developer, but occasionally people send me patches.
Concretely, I have one folder in my filesystem called “FsCheck”. In that, I have one repository, and thus folder, called main. Typically, I have a few folders next to that where I work on specific features or bug fixes or whatever, say bug-escapingexceptions and feat-statefulchecking and patch-userFoo. These are created using hg clone.
When I’m done with a feature or bugfix, I commit everything in that folder and push to main. Possibly merge in main. (hg commit, hg push, hg merge). Then I delete the folder (careful using hg status and hg outgoing that I’m not throwing away something useful).
I almost never work in main except right before a release, where I do final cleanup (say documentation). Before release, I tag in main with the release number (hg tag v0.5.1).
Codeplex uses svn as sourcecontrol. I only use it as to store releases, for which I use a locally checked out SVN working copy, to which I copy the Mercurial repository using hg archive. Then commit using svn. Primitive, but it works (using Mercurial as an SVN ‘super client’ on windows isn’t very user-friendly yet in my opnion)
I haven’t had to do maintenance on previous releases yet, but I would do that by cloning the main repository from that release’s revision(this is easy, since I tagged it), and work in that separate repository. Merging back to the main trunk would be as easy as pushing the changes to main and merging.
In summary:
- One folder to store all your project’s repositories, with the name of your project
- In that folder one main repository, and one transient repository per “unit of work”, with a descriptive name for the unit of work.
It’s nice cause your branches and what you’re working on is intuitively visible in the filesystem.