Difference between revisions of "Mercurial/Migration"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Summary migrations)
Line 10: Line 10:
 
{{Template:Documentation/Tip| Just because the "official" repositories contain no branches doesn't mean that you can't use branches in your daily work. Actually you will work with several [http://mercurial.selenic.com/wiki/Head ''heads''] every time you do merge work. If you want to keep long term branches in your working repository use [http://mercurial.selenic.com/wiki/NamedBranches ''named branches''] or [http://mercurial.selenic.com/wiki/BookmarksExtension ''bookmarks'']}}
 
{{Template:Documentation/Tip| Just because the "official" repositories contain no branches doesn't mean that you can't use branches in your daily work. Actually you will work with several [http://mercurial.selenic.com/wiki/Head ''heads''] every time you do merge work. If you want to keep long term branches in your working repository use [http://mercurial.selenic.com/wiki/NamedBranches ''named branches''] or [http://mercurial.selenic.com/wiki/BookmarksExtension ''bookmarks'']}}
  
Subversion branches are mapped as follows
+
Subversion branch mapping
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 39: Line 39:
 
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.
 
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? =  
+
=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.
 
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 =
+
=Mercurial based child workspaces from the pilot phase=
  
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 incrementally updated DEV300 Mercurial pilot repository will be simply elevated to be the main repository. This means that your child workspaces from the Mercurial pilot and implementation phase can be used just as they are. No migration needed.
  
==The SVN based CWS is nearly ready, not many conflicts expected on integration==
+
= Migrating SVN based child workspaces to Mercurial =
  
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:
+
There are several options how to handle open child workspaces which are SVN based. Pick the one wich is most suitable for your CWS.
 +
 
 +
==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 integration of your CWS. The constraints:
 
* SVN child workspaces which have never been rebased will always be integrated with "change for change" history preserved.
 
* 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.
 
* 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==
+
==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.  
 
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.  
 +
 +
{{Template:Documentation/Note| You might wonder why all this fuss over rebasing? Converting SVN changesets into Mercurial changesets is relative straightforward process. But SVN rebase changesets are really huge beasts which can't be simply converted to Mercurial because they would introduce incredible bloat. On the other hand they cannot be completely ignored because they contain some valuable information: the merge conflict resolutions.}}
  
 
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.
 
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==
+
==SVN based CWS is work in progress and has already been rebased==
  
The majority of open CWSs fall probably in this category.
+
Probably the majority of open child workspaces fall in this category.
  
 
Two options:  
 
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.
 
* 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.
 
* You can do a summary migration yourself as described below. No RE intervention required but you loose the "change for change" history.
 +
 +
==SVN based CWS where nothing has been committed yet==
 +
 +
The trivial case. Just toggle the SCM selector in the CWS EIS page from SVN to HG.
  
 
==Migrations done by RE==
 
==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.
 
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.
 +
 +
{{Template:Documentation/Note| A trial conversion of CWS printerpullpages took about 3h. This CWS orginated in CVS, has been rebased seven times and contained 460 changesets. This is probably the worst case we'll encounter.}}
  
 
==Summary migrations==
 
==Summary migrations==
Line 114: Line 126:
 
6) Commit the changes
 
6) Commit the changes
  
7) Toggle the SCM selector in the CWS EIS view from SVN to HG. After about an hour the 'outgoing' repository of your CWS will be available.
+
7) Toggle the SCM selector in the CWS EIS page from SVN to HG. After about an hour the 'outgoing' repository of your CWS will be available.
  
 
8) Your CWS is now Mercurial 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 work.
 
8) Your CWS is now Mercurial 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 work.
  
 
= Converting a CVS based CWS to Mercurial =
 
= Converting a CVS based CWS to Mercurial =

Revision as of 21:41, 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.

Documentation caution.png 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 branch mapping

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.

Mercurial based child workspaces from the pilot phase

The incrementally updated DEV300 Mercurial pilot repository will be simply elevated to be the main repository. This means that your child workspaces from the Mercurial pilot and implementation phase can be used just as they are. No migration needed.

Migrating SVN based child workspaces to Mercurial

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

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 integration of your CWS. The constraints:

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

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.

Template:Documentation/Note

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.

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

Probably the majority of open child workspaces fall 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.

SVN based CWS where nothing has been committed yet

The trivial case. Just toggle the SCM selector in the CWS EIS page from SVN to HG.

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.

Template:Documentation/Note

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 CWS EIS page from SVN to HG. After about an hour the 'outgoing' repository of your CWS will be available.

8) Your CWS is now Mercurial 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 work.

Converting a CVS based CWS to Mercurial

Personal tools