I am yet another Subversion user struggling to re-educate myself in the Tao of distributed version control.
When using Subversion, I was a big fan of the project-minor approach, and, with most of my former employers, we would structure our repository branches; tags & trunk as follows:
branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk
Within the actual source tree itself, we would use (something like) the following structure:
(src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | +-utilities +-libraries-+ | +-log-+ | | +-build | | +-doc | | +-test | +-statistics-+ | | +-build | | +-doc | | +-test | +-charting-+ | | +-build | | +-doc | | +-test | +-distributedComputing-+ | | +-build | | +-doc | | +-test | +-widgets-+ | +-build | +-doc | +-test +-productLines-+ | +-flagshipProduct-+ | | +-coolFeature | | +-anotherCoolFeature | | +-build | | +-doc | | +-test | +-coolNewProduct +-project-+ +-bigImportantCustomer-+ | +-bespokeProjectOne | +-bespokeProjectTwo +-anotherImportantCustomer-+ +-anotherBespokeProject
The idea was (and still is) to use the structure of the repository to help structure communication between the engineering team; the customer-facing part of the business and various other stakeholders & domain experts.
To wit: Source documents that sit in one of the "project" directories get used (and earn money) only once. Documents that sit in one of the "productLines" directories earn money as many times as a product from that particular line gets sold. Documents that sit in one of the "libraries" directories earn money as many times as any of the products that use them get sold.
It makes the notion of amortization of costs explicit, and helps build support for source document reuse across the business.
It also means that there is a common structure over which our build automation tools can operate. (Our build scripts walk the source tree looking for "build" folders within which they find configuration files specifying how each component is to be built; a similar process happens for documentation generation and testing).
Significantly, the products on which I work typically take a LONG time to run performance measurement & characterization tests; from 20 to 200 hours; generating somewhere between several GB to several TB of processed test results/intermediate data (that must be stored and tied to a particular system configuration so performance improvement over time can be measured). This issue makes configuration management an important consideration, and also imposes some requirement for centralisation, as typically the computational resources needed to run the performance measurement and characterization tests are limited; (a small cluster of 64-128 cores).
As one final note; the continuous integration system knows that it needs to trigger a build; static analysis; smoke test & unit test run each time trunk is modified, each time any "tag" branch is modified, and each time any "AUTOMATED" branch branch is modified. This way, individual developers can use the CI system with their personal branches, an important capability, IMHO.
Now, here is my question: How can I replicate all of the above (and improve upon it, if possible), with Mercurial.
My current line of thinking is to use a central Subversion Repository, to define the overall structure, but to allow the use of hg as a client so developers can have repos available locally.