Revision as of 20:35, 22 October 2009

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.

Template:Documentation/Tip

Subversion branches are mapped as follows

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.

Migrating 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.

The 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.

The 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.

The 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 CWS 'foo'

1) Find out the current milestone of the CWS.

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

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

2) Create a diff of the current milestone against your CWS

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

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

3) Create a Mercurial clone of the current milestone

hg clone -r DEV300_mXX <local_DEV300_copy> foo

4) Apply the patch

cd foo
patch -p0 < foo.patch

The patch should apply cleanly, without any fuzz.

5) Take care of added and removed files. Depending on the patch tool removed files might still be there but have zero size. If your CWS changed binary files, double check that the working tree contains the right version. If in doubt use diff -r to compare the HG working tree with a checked out SVN copy of your child workspace.

6) Commit the changes

7) Toggle the SCM selector in the EIS view of the CWS from SVN to HG. After about an hour the 'outgoing' repository of your CWS will be available.

8) Your CWS is now hg based. If you want to update it to a recent milestone just pull from DEV300 and merge. Push to the outgoing repository to publish your changes.

Converting a CVS based CWS to Mercurial