- 1 OpenOffice.org migrates to Subversion
- 1.1 Trunk only migration
- 1.2 Required tools
- 1.3 Migrating a child workspaces for DEV300 from CVS to SVN
- 1.4 FAQ
OpenOffice.org migrates to SubversionAfter a long discussion and preparation time it finally happens, OpenOffice.org migrates with milestone DEV300 m31 to a new SCM (Software Configuration Management) system. The new SCM system will be Subversion (SVN) for now, which might disappoint the one or other who had hoped for a distributed SCM like Git, Bazaar or Mercurial. Please be assured that we'll keep our mind open and we'll reevaluate the fast moving SCM tooling situation periodically. We were very careful to make certain that our move now to Subversion does not preclude a move to a DSCM in the future.
Trunk only migration
Milestone DEV300 m31 is the last milestone which has been integrated via CVS and is the first milestone which is available in SVN. We did a trunk migration only. The trunk (DEV300) code line will be maintained via Subversion only starting with milestone DEV300 m32. Old code lines, including the OOo-3.0 release codeline(OOO300) will still be maintained via CVS.
Please let me repeat this: we did not migrate branches and tags to SVN. There are a number of advantages (and some disadvantages as well) to this approach. A discussion of the merits of different approaches to the actual repository conversion can be found here.
The most important reasons for choosing the "trunk only" approach were:
- No quiet time for developers
- The conversion of historical workspaces from CVS to SVN would be fragile at best due to some liberties we took in structuring our CVS repository. Having no historical branches and tags is preferable to having inaccurate branches and tags IMHO.
The "trunk only" approach enabled us to optimize the resulting SVN repository, it shrunk from 90 GBytes to about 6 GBytes overall size. The following rules have been applied during conversion
- Only modules which have active content in DEV300 m31 are included in the conversion.
- All files in "Attic" have been removed.
- All but the last revisions of binary files have been dropped - after all you can't diff them anyway
- All but the last revisions of "localize.sdf" files have been dropped - saves an incredible amount of repository space without losing much
- subversion-1.5.4 or later; download...
- ssh for committers, preferably OpenSSH 2.4 or later
We make heavy use of the new SVN merge tracking feature. So please do not use a SVN client older than subversion-1.5.4 if you work on a child workspace (CWS). Please note, subversion-1.5.1 is known to break things in the Openoffice.org context and subversion-1.5.3 has been hastily replaced by the subversion developers because it can break mergetracking.
Windows users most certainly want to take a look at TortoiseSVN and lots of documentation available at http://tortoisesvn.net/
You will find a walkthrough on how to set up svn clientside on Setting up Subversion Access
Migrating a child workspaces for DEV300 from CVS to SVN
Let's assume your CVS based CWS is called 'foo42' and you have finished the subversion and the cws tooling setup.
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: 220.127.116.11
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.
7) Check out the OOo trunk with
$ svn checkout svn+ssh://email@example.com/ooo/trunk my_working_copy
8) Configure and source the configured script as usual
$ cd my_working_copy/config_office $ configure ... $ cd .. $ source LinuxX86Env.Set.sh # YMMV
9) Create the CWS branch in SVN
$ cws create --migration -m m32 DEV300 foo42
This command creates the CWS branch in Subversion based on milestone DEV300 m32 and updates the "current milestone" information in EIS. Milestone DEV300 m32 is essentially the same as DEV300 m31 (just a few fixes for SVN and CWS tooling).
The --migration switch tells the cws create command that an existing CWS is migrated. Without the switch, EIS will complain that your CWS already exists.
10) Switch your working copy to your CWS branch
$ cd my_working_copy $ svn switch svn+ssh://firstname.lastname@example.org/ooo/cws/foo42 ... $ svn info Path: . URL: svn+ssh://email@example.com/ooo/cws/foo42 Repository Root: svn+ssh://firstname.lastname@example.org/ooo Repository UUID: 8da58560-a4e7-4996-a0c2-a735b94b261c ...
Check the URL: line of the output of svn info. It should point to your CWS branch. Please be extra certain that you never commit anything on trunk. You can always check the branch on which you are working with svn info.
11) Apply the patch
$ cd my_working_copy $ patch -p1 < foo42.diff
Since DEV300 m31 and DEV300 m32 are almost identical, your patch should apply cleanly. If you get rejects you'll need to fix them manually. The patch tool handles added and removed files quite nicely, the first ones are created by patch, the latter ones appear as zero byte sized files in the tree.
12) Handle added and removed files
This is pretty straight forward. You need to tell SVN which files have been added or removed by your patch.
$ svn add <list_of_added_files> $ rm <list_of_removed_files> $ svn remove <list_of_removed_files>
13) Commit the changes to your CWS branch
Review all changes with
$ svn status $ svn diff
and if everything is OK, commit them to your branch
$ svn commit -m"#iXXXXX#: migrate CWS foo42 to SVN."
Remember, always check that your working copy has been switched to the CWS branch before committing.
Do I really need to resync first to DEV300 m31 in CVS? Can I use a later milestone than DEV300 m32 in SVN?
No and yes resp. If you are certain that your patch applies cleanly or you are prepared to handle the rejects, you can skip the resync part of the recipe or/and start of from a newer SVN based milestone. Working with DEV300 m31 (CVS) and DEV300 m32 (SVN) almost ensures that the patch applies cleanly which is why we recommend to work with them.
Why not just wait until one of the DSCM systems emerges as a clear front runner?
Well, first, this might never happen because each of the mentioned DSCM system emphasizes certain strength, leaving no one clear winner in all categories (ease of use, performance, integration possibilities and platform support). Second, and this is way more important, the OpenOffice.org CWS/CVS system is crumbling under the heavy weight of 8 years worth of OOo coding.