Mercurial Pilot

Mercurial Pilot

The purpose of the Mercurial(Hg) Pilot for OOo is to find out if our DSCM tool of choice can stand the harsh realities of the OOo development process. The OOo code base is pretty huge and we want to know if there are scalability and usability issues before we commit ourselves to a (hopefully) very long lasting SCM tool for OpenOffice.org. After all SCM migrations are no fun, indeed.

The OOo Mercurial Pilot is expected to last at least 2 month. This is necessary to ensure that some "old enough" hg hosted child workspaces exist to check out how well the updating/re-sychronizing/re-basing works, something which is considerably painful with SVN. If we find that the pilot doesn't expose some hidden Mercurial problems we'll switch over completely to Mercurial as soon as the necessary infrastructure for a full scale hg usage is in place. If substantial problems surfaces during the Pilot we might extend the Pilot time frame to see if the problem can be overcome, or, in an extreme case, even set up a new Pilot with git or bazaar.

The details:

• The pilot will only cover the main development code line (aka trunk in SVN).
• The master repository can be found here: http://hg.services.openoffice.org/ooo/default. This repository is updated from the SVN trunk on a regular base.
• After a CWS is finished, it is necessary to pull/merge one final time to help the REs with clean patches.
• RE will pull from your hg hosted CWS, export your changes and apply it as patch to the SVN trunk.

The pilot covers the following areas:

• The complete CWS life cycle from a developers point of view, this includes cloning, committing, pulling, merging and re-basing.
• Parts of the CWS handling for RE: pulling from developers, merging.

What is not tested:

• Transplanting changesets from one code line to another. RE will set up separate tests for this.
• Integration is done via SVN, thus pushing to the master repository on the remote server by REs is not tested. No problem, this problem is only by convention different from the developer repositories.

Since every change will still have to be integrated via SVN there are a few caveats which you will need to consider if you plan to participate in the pilot:

• Your commits (changesets) will loose their identity during integration. This might make problems if you cross merged changessets between several CWSs.
• Integration will lump all commits of your CWS into one single commits.
• The single commit will contain of course a single commit message. If possible I'll try to lump all commit messages of your commits together via scripting. Alternatively REs will accept a detailed commit message supplied by you.
• The author of the hg commits is lost as well because a RE engineer will do the integration commit to SVN. If scripting works we'll include the original author info into the commit message.
• Be careful with renaming files. If you do a lot of renaming you'll most probable cause a lot of stress on the integrator. Remember, the RE integrate your CWS via diff and patch. Also, all restrictions of SVN regarding the renaming of files/directories still apply. If you plan to do a lot of renaming please do it on a SVN based repository. Or better, if possible, wait for the final switch to hg.