Mercurial/Migration
|
|
|---|
|
Quick Navigation |
| About this template |
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. |
 |
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 heads every time you do merge work. If you want to keep long term branches in your working repository use named branches or bookmarks. |
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.
|
You might wonder why all this fuss over rebasing? Converting SVN changesets into Mercurial changesets is a 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. So rebase changesets have to be handled separately |
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.
|
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 (patch) 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 'foo42'
SVN tasks
1) Find out the current milestone of the CWS.
$ export SVNOOO=svn://svn.services.openoffice.org/ooo $ svn log --stop-on-copy $SVNOOO/cws/foo42 | 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/foo42 > foo42.patch
Double check the patch. It should definitely show only *your* changes, never anything which has been introduced via rebases. Remove trivial changes.
3) Search the patch for lines which starts with
diff -u /dev/null <some_file>:<some_revision>
These files have been added to your CWS. Note the filenames down, you'll need them later.
4) Search the patch for lines which end with :removed
diff -u <some_file>:<some_revision> <some_file>:removed
These files have been removed in your CWS. Note the filenames down, you'll need them later.
HG tasks
5) Create a Mercurial clone of the current milestone
$ hg clone -r DEV300_mXX <local_DEV300_copy> foo42
6) Apply the patch
$ cd foo42 $ patch -p0 < foo42.patch
The patch should apply cleanly, without any fuzz.
7) 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.
8) Commit the changes
9) 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.
10) 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
CVS tasks
1) Find out the CVS branch tag and anchor tag of your CWS.
$ cd <added_module>
$ cvs log <some_file_which_already_existed_before_your_cws> | grep -i foo42
CWS_SRC680_FOO42_ANCHOR: 1.36
cws_src680_foo42: 1.36.0.44
The first tag (CWS_SRC680_FOO42_ANCHOR) is your anchor tag, the second tag (cws_src680_foo42) is your branch tag. Note them down.
2) Rebase your CVS based CWS to milestone DEV300 m31 with the old CWS tools
$ cwsresync -m m31 all ... solve conflicts ... $ cwsresync -c all
3) Create a patch containing all modules. It is recommend to use the "rdiff" CVS command. A "rdiff" is quite handy for this purpose, because it allows the creation of one patch for all "added" modules. Use the "-u" switch for creating a so called "unified context patch".
$ cvs -d <your_tunnel_setup> rdiff -u -rCWS_SRC680_FOO42_ANCHOR -rcws_src680_foo42 `cwsquery modules` > foo42.patch
4) Check the patch for consistency. It should contain only stuff you did on your CWS. Throw out trivial changes.
5) Search the patch for lines which starts with
diff -u /dev/null <some_file>:<some_revision>
These files have been added to your CWS. Note the filenames down, you'll need them later.
6) Search the patch for lines which end with :removed
diff -u <some_file>:<some_revision> <some_file>:removed
These files have been removed in your CWS. Note the filenames down, you'll need them later.
HG tasks
7) Create a Mercurial clone of the current milestone
$ hg clone -r DEV300_m31 <local_DEV300_copy> foo42
8) Apply the patch
$ cd foo42 $ patch -p0 < foo42.patch
The patch should apply cleanly, without any fuzz.
9) 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.
10) Commit the changes
9) 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.
11) 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.
