Revision as of 11:29, 8 May 2009

Mercurial Pilot

Purpose

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.

Timeline

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 will 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/hg/DEV300. This repository is hourly updated from the SVN trunk.
• After a CWS is finished and QAed, it is necessary to pull/merge/push one final time in case of expected conflicts 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.

What the pilot covers

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

What is not covered

• Transplanting changesets from a release code line to the main development line. 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 repository is only by convention different from developer repositories.

Caveats

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 changesets will loose their identity during integration. This might create problems if you cross merged changesets between several CWSs.
• Integration will lump all changeset of your CWS into one single changeset.
• The single changeset commit during integration will contain of course only a single commit log. If possible I'll try to lump all commit logs of your changesets together via scripting. Alternatively REs will accept a detailed commit log supplied by you.
• The author of the hg changesets 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 log.
• 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.
• Tinderboxes, buildbots etc will have to be adapted to Mercurial, this will take some time.

I'm an OOo domain developer, what to do if I want to participate?

Please send me (hr@openoffice.org) a note that you plan to participate. I will setup your public ssh key so you can push your changesets to an outgoing repository on hg.services.openoffice.org. It's not mandatory that you use this server to publish your changes, but at integration time latest the RE will naturally need to access your repository somewhere. It is planned to offer this server as central publishing point for OOo CWSs to ease the development coordination. An overview of active hg hosted CWSs can be found here: http://hg.services.openoffice.org/hg/cws.

Example

Let's say you want to participate in the pilot with your new CWS 'mycws', based on DEV300 m47. The steps are: (see OOo and Mercurial for general mercurial workflow info)

• clone the repository

$ hg clone -r DEV300_m47 http://hg.services.openoffice.org/hg/DEV300

Note: well, most probably you will simply clone from your locally held regularly updated pristine copy of that repository. The current repository size is ~1.2 GB, cloning from the server takes about 50min over a 4MBit DSL line.

• configure, etc
• create a dummy entry for your CWS in the SVN repository, register your CWS with EIS

$ cws create -m m47 DEV300 mycws

• send me (hr@openoffice.org) a note with name and the current milestone of your CWS if you plan to use hg.services.openoffice.org as outgoing server. I'll then create a server side clone of the master repository to serve as your outgoing repository. This safes time (270000 changesets less to push over the line) and server diskspace (hard links). This operation will be the first candidate for automation, of course ...
• hack away in your CWS ...
• push your changes to the outgoing repository for publishing if you feel so

$ hg push  ssh://hg@hg.services.openoffice.org/cws/mycws

• pull/merge from the repository to re-synchronize your CWS from a new milestone, say DEV300_m52

$ hg pull -r DEV300_m52 http://hg.services.openoffice.org/hg/DEV300
$ hg merge

Note: if you haven't published your repository yet, 'hg rebase' is an option to consider.

• QA,fixes, etc
• final pull/merge/push cycle to ease the integration into SVN trunk.

Mercurial extensions you might want to have look at

• hg rebase: git style rebasing instead of pull/merge
• hg transplant: cherry picking of changsets from other CWSs
• hg win32text: if you work on windows