Mercurial/Migration

Mapping OOo CVS and SVN development branches to Mercurial

In the Openoffice.org Mercurial setup CVS and SVN branches are represented by a repository of their own. This is a common setup for a DSCM, although all of the big three DSCMs (Git, Bazaar and Mercurial) support mechanisms to keep more than one branch in one repository. Our development process doesn't really require us to keep more than one branch per repository so we can spare us the additional complexity.

In the DSCM world the word "branch" describes several quite varying concepts. So called "named branches" are the closest Mercurial representation of what a branch inside one repository would be for CVS and SVN users.

Subversion branches are mapped as follows

SVN	HG
<svnroot>/trunk	DEV300
<svnroot>/branches/OOO320	OOO320
<svnroot>/branches/OOO310	OOO310
<svnroot>/cws/vcl95	cws/vcl95
<svnroot>/cws/vcl96	cws/vcl96
<svnroot>/cws/...	cws/...

Eventually, old CVS based code lines (like OOH680) will be made available as hg repositories, but this is not yet high on the priority list.

Which codeline will be migrated first?

DEV300, that is the current development codeline on the way to OOo 3.3. The OOo 3.2.x codeline will follow later. It is anticipated that the last SVN based milestone on code line DEV300 is m63, and the first HG based one is DEV300 m64.

Converting a SVN based CWS to Mercurial

There are several options on how to handle open child workspaces which are still SVN based. Pick the one wich is most suitable for your CWS.

My SVN based CWS is nearly ready, not many conflicts expected on integration

Great! If your CWS has been opened on a recent milestone and never been rebased, just do nothing. If your CWS is on an old milestone than do one last cws rebase to bring it up to DEV300 m63. Please state in the CWS description if you want the "change for change" history preserved or if you can live with a summary changeset of your CWS. The constraints are as follows:

• SVN child workspaces which have never been rebased will always be integrated with "change for change" history preserved.
• SVN child workspaces with one or more rebases require significantly more effort to be integrated without losing the change history so RE might opt for doing a summary integration with patch. RE will honor the wishes of the CWS owner but might delay the integration of your CWS for a milestone or two if to busy.

My SVN based CWS is work in progress and has never been rebased

Great! Apply immediately for a migration slot. Do not rebase it with SVN, just wait for the migrated repository to appear on hg.services.openoffice.org and then do a pull/merge cycle to bring it up-to-date. Of course you can continue to commit your normal work just don't do unnecessary rebases.

If you just can't wait for the lazy guys in RE to do their migration job you can still do a summary migration yourself. See below.

My SVN based CWS is work in progress and has already been rebased

The majority of open CWSs fall probably in this category.

Two options:

• Apply for a migration slot with RE and wait for the migration to happen. Just continue your normal work on the CWS. You can rebase your CWS, just not beyond DEV300 m63.
• You can do a summary migration yourself as described below. No RE intervention required but you loose the "change for change" history.

Migrations done by RE

Send all requests for CWS migrations to hr@openoffice.org. First come, first served. The migrations will start in earnest Nov. 9th 2009, after the OOo conference in Orvieto.

Summary migrations

The following procedure can be used to migrate your CWS yourself:

• Advantage: you don't need to wait for RE
• Disadvantage: you loose the "change for change" history of your CWS

Say you want to migrate your CWS 'foo'

• Find out your current milestone

export SVNOOO=svn://svn.services.openoffice.org/ooo
svn log --stop-on-copy $SVNOOO/cws/foo | grep CWS-TOOLING

will show you all rebases of the CWS, if any. Of course the current milestone should be identical to the one stored in EIS.

• Say the current milestone is DEV300 m52. Create a diff against the current milestone

svn diff $SVNOOO/tags/DEV300_m52 $SVNOOO/cws/foo > foo.patch

Double check the patch. It should definitely show only *your* changes, never anything which has been introduced via rebases.