Difference between revisions of "OOo and Subversion"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
Line 129: Line 129:
 
The subcommands do more or less what their CVS predecessors did.
 
The subcommands do more or less what their CVS predecessors did.
  
*Create a CWS
+
====Create a CWS====
  
 
Create a CWS with the <tt>cws create</tt> subcommand. Please note that this commands only creates a CWS branch on the OOo server and registers it with EIS. It changes nothing on your hard disk.
 
Create a CWS with the <tt>cws create</tt> subcommand. Please note that this commands only creates a CWS branch on the OOo server and registers it with EIS. It changes nothing on your hard disk.
Line 149: Line 149:
  
 
  svn://svn.services.openoffice.org/ooo/cws/foo
 
  svn://svn.services.openoffice.org/ooo/cws/foo
 +
  
 
for check out.
 
for check out.
  
 +
====Check out a CWS====
 +
 +
cws fetch foo
 +
 +
Currently this simply checks out your cws ''foo'' just as if you had issued the command
 +
 +
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/cws/foo
 +
 +
Over time I'll add a number of convenience functions to <tt>cws fetch</tt>, like configurable partial checkouts, use of prebuild solvers, switching CWSs etc etc.
 +
 +
Please note that if you have already a OOo SVN working copy lying around, you can save considerable checkout time with the svn switch command.
 +
 +
cd <wc>
 +
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/foo
 +
 +
will fetch the differences between your working copy in <wc> and the CWS ''foo''
 +
 +
====Rebasing a CWS====
  
*Check out a CWS
+
The successor of the <tt>cwsresync</tt> tool is called <tt>cws rebase</tt>. rebasing is now a two step operation:
  
cws fetch foo
 
  
Currently this simply checks out your cws
 
  
  

Revision as of 15:53, 8 September 2008

[ This page is under constrcution. I'll add more content over the next few days. HR]


OpenOffice.org migrates to Subversion

After 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.
Documentation note.png why

Trunk only migration

Milestone DEV300 mxx 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 mxx 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 loosing much

Required tools

  • subversion-1.5.1 or later
  • 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.1

Subversion documentation

The excellent Subversion documentation can be found here: http://svnbook.red-bean.com. Please use the nightly build documentation for 1.5 and later, it covers new features like merge tracking.

Please read at least the "basic usage" part of the documentation!
.
CWS tooling is only a very thin layer around the SVN client hiding the lengthy URLs from sight plus some bookkeeping. Everything else is plain Subversion.

Server access methods

Read only access

svn co svn://svn.services.openoffice.org/ooo/trunk

or

svn co http://svn.services.openoffice.org/ooo/trunk

Read/write access

Write access to the repository requires a ssh setup.

svn co svn+ssh://svn@svn.services.openoffice.org/ooo/trunk

Ssh setup

[Tbd.]

CWS tooling

The CWS tooling has been reworked to adapt to SVN. The basic CWS tool is now simply called cws and is invoked as cws <subcommand> in the style of the SVN client, there are no longer separate tools like cwsadd, cwsresync etc etc.

The most important change in the way CWSs are handled now is that there is no longer a need nor possibility to add modules. Well, there is still a sw and config_office but all modules of old are now just top level directories, at least as far as SVN is concerned.

CWS config file

Please keep all your entries in your $HOME/.cwsrc for now, you'll need them if you want to work with CWSs for OOo-3.0. Just add the following line to refer to the OpenOffice.org SVN server:

SVN_SERVER=svn+ssh://svn@svn.services.openoffice.org/ooo

Example of a complete .cwsrc file:

[CWS_CONFIG]
# Network proxy for EIS connections. 
# Comment in if you need to access EIS via a proxy.
# Note: This is just for accessing the EIS database. For SVN have a look here:
# http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.servers
# Example: PROXY=http://myproxy.company.com:8080
# PROXY=

# CWS Database server (SOAP). It's possible specify to several backup server,
# currently there are none.
CWS_DB_SERVER_1=https://eis.services.openoffice.org/soap/servlet/rpcrouter

# Your CVS login (for authentication with the CWS database).
CVS_ID=<your_ooo_name>

# Your scrambled CVS password (for authentication with the CWS database).
# Take this one from .cvsrc
CVS_PASSWORD=<your_current_cvs_scrambled_ooo_password>

# OOo CVS tunnel
# Example: CVS_SERVER_ROOT=pserver:cvs_id@mytunnel.mydomain.de:/cvs
CVS_SERVER_ROOT=

# Path to the cvs binary (optional)
# Example: CVS_BINARY=/usr/bin/cvs
#CVS_BINARY=

# SVN server for OOo-3.1 child workspaces
# r/w access via svn+ssh pprotocol
SVN_SERVER=svn+ssh://svn@svn.services.openoffice.org/ooo
# r/o access via svn protocol
#SVN_SERVER=svn://svn.services.openoffice.org/ooo

Working with the new cws tool

Help can be invoked with:

cws help

which yields

cws -- version: 1.1.2.10
usage: cws <subcommand> [options] [args]
Type 'cws help <subcommand>' for help on a specific subcommand.

Available subcommands:
        help (h,?)
        create
        fetch (f)
        rebase (rb)
        analyze (an)
        query (q)
        task (t)
        integrate *** release engineers only ***
        eisclone *** release engineers only ***
help (h, ?): Describe the usage of this script or its subcommands
usage: help [subcommand]

The subcommands do more or less what their CVS predecessors did.

Create a CWS

Create a CWS with the cws create subcommand. Please note that this commands only creates a CWS branch on the OOo server and registers it with EIS. It changes nothing on your hard disk.

Example: create CWS foo on the latest published milestone of master DEV300

cws create DEV300 foo

Of course you can specify which milestone you want to use, here is the complete command reference:

cws -- version: 1.1.2.10
create: Create a new child workspace
usage: create [-m milestone] <master workspace> <child workspace>
       -m milestone:          Milestone to base the child workspace on. If ommitted the
                              last published milestone will be used.
       --milestone milestone: Same as -m milestone.

Your CWS branch is then available as

svn://svn.services.openoffice.org/ooo/cws/foo


for check out.

Check out a CWS

cws fetch foo 

Currently this simply checks out your cws foo just as if you had issued the command

svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/cws/foo

Over time I'll add a number of convenience functions to cws fetch, like configurable partial checkouts, use of prebuild solvers, switching CWSs etc etc.

Please note that if you have already a OOo SVN working copy lying around, you can save considerable checkout time with the svn switch command.

cd <wc>
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/foo

will fetch the differences between your working copy in <wc> and the CWS foo

Rebasing a CWS

The successor of the cwsresync tool is called cws rebase. rebasing is now a two step operation:



Tips and tricks

[Tbd.]

Notes

Documentation note.png why
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.
Views
Personal tools
Navigation
Tools