At work we use two different major version of Subversion : 1.5 for our own repositories and 1.6 for everything that come from others repositories (Apache, Google Code, ...).

Reason is that we do not have time to upgrade to Subversion 1.6, and we cannot commit to Google Code without 1.6 client.

svn: This client is too old to work with working copy

It's dangerous to use 1.6 client with 1.5 working copies because Subversion 1.6 working copy format was upgraded from 1.5, this means that :

• 1.5 and older Subversion clients will not be able to work with working copies produced by Subversion 1.6
• Working copies are upgraded automatically
• We get a svn: This client is too old to work with working copy message too often

Recently we made two mistake using Tortoise SVN and Subclipse for Eclipse Helios newest version in two different places, a linux server via Samba, and my Windows computer.

Nobody is able to work with theses upgraded working copies, getting this message

svn: This client is too old to work with working copy '.'.  You need
to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.

Working copy format change with Subversion 1.6

Subversion becomes Apache Subversion in 2010, let's check the new documentation URL on subversion.apache.org.

Sometimes the working copy metadata format changes incompatibly between minor releases. For example, say you have a working copy created with Subversion 1.4.4, but one day you decide to try out Subversion 1.5.0. Afterwards, you attempt to switch back to 1.4.4, but it doesn't work — it just gives the above error.

This is because 1.5.0 upgraded your working copy format to support some new features (in this case, changelists, the keep-local flag, and variable-depth directories). Although 1.4.4 doesn't know anything about these new features, it can at least recognize that the working copy format has been upgraded to something higher than it can handle.

Subversion team distribute a Python script that can downgrade working copies safely because this automatic upgrade behavior can be annoying.

Linux part : change-svn-wc-format.py Python script

Download and installation

We need to first download the change-svn-wc-format.py script

wget http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py

Then don't forget to give execution right to it

chmod +x change-svn-wc-format.py

Testing if everything work by checking the help

 ./change-svn-wc-format.py --help
usage: change-svn-wc-format.py WC_PATH SVN_VERSION [--verbose] [--force] [--skip-unknown-format]
       change-svn-wc-format.py --help
Change the format of a Subversion working copy to that of SVN_VERSION.
  --skip-unknown-format    : skip directories with unknown working copy
                             format and continue the update

If you don't see this message, you probably got a Python error, this script use Python 2.X, check Google to help you on this subject as i'm not a specialist on it.

Downgrading working copy

I want my working copy to be downgraded to Subversion 1.5 and to see what happen so let's use this command :

./change-svn-wc-format.py /my/broken/WC/path/. 1.5 --verbose

I strongly suggest you to use --verbose, because using change-svn-wc-format.py in a path that does not exists say that ... it worked.

./change-svn-wc-format.py /this/path/does/not/exists/. 1.5
Converted WC at '/this/path/does/not/exists/.' into format 9 for Subversion 1.5

Now on a real working copy

Processing directory '.'
Parsing file '/my/broken/WC/path/.svn/entries'
Updating file '/my/broken/WC/path/.svn/format'
/my/broken/WC/path/.svn/format does not exist, creating it.
Checking whether WC format can be converted
Writing WC format
[...]
Writing WC format
Converted WC at '/my/broken/WC/path/' into format 9 for Subversion 1.5

A simple status command to check everything :

svn status -u
Status against revision:    604

It worked !

Windows part for change-svn-wc-format.py

Python download and installation

Subversion script use Python 2.X, so download it from this download page, then install it.

Add Python directory (C:/Python27 here) to your Windows environment variable "Path", open Control Panel > System > Advanced Panel > Environment variables > Path > Modify.
A screen in a french Windows XP can help you /blog/public/windows_python_env_path.png.

Download and test change-svn-wc-format.py

Open http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py and "Save As" the script on your computer.
Then open a DOS command prompt windows and execute this command to check correct python installation

python change-svn-wc-format.py --help

If you 've got the following message your are using Python 3.X and you need to install Python 2.X

  File "change-svn-wc-format.py", line 99
    except UnrecognizedWCFormatException, e:
                                        ^
SyntaxError: invalid syntax

Both version can be installed at the same time, but only one can be put in Windows environment variable "Path" or you can try the conversion tool for Python 2.x code from 2to3 tools.

Downgrading working copy

Open a DOS command prompt windows then execute

C:\>python change-svn-wc-format.py c:/my/broken/working/copy 1.5 --verbose
Processing directory 'c:/my/broken/working/copy.'
Parsing file 'c:/my/broken/working/copy.svn/entries'
Updating file 'c:/my/broken/working/copy/.svn/format'
[...]
Converted WC at 'c:/my/broken/working/copy' into format 9 for Subversion 1.5

Again I strongly suggest you to use --verbose using change-svn-wc-format.py in a path that does not exists say that ... it worked.

Hope that after losing hour after hour we finally get some green light to upgrade Subversion.

Why use svnsync, there already a repository !

All our websites are put into production using subversion (But not directly, first we update an hidden working copy, then rsync it on filer).

We use minify and log4php with svn:externals and want to keep it versionned to easily switch to new release but don't want to be dependent on code.google.com or apache.org repositories, that sometime goes into 502 or 503, to put new releases in production.

code.google.com or apache.org permit us to use svnsync, let's see how to easily use it. Note that you can use Google Code repository as a mirror and have your master repository on your server (in case you own the project), but keep in mind that wiki is also in project repository, so front end modification on wiki will alter your mirror repository, and break the sync.

Create the mirror repository

svnadmin create /repos/minify

At work, subversion is on an "open bar" mode, no user authentication required at all, we've got a general user, and a svn superuser, no use of username or sync-username.

Let's make the svn superuser the only able to commit and edit properties on the mirror repository, the mirror must be read-only for any method other than 'svnsync'.

To do that we must enable revision property changes and commit to the dedicated server account on the mirror repository.

Enable the pre-revprop-change hook

vi minify/hooks/pre-revprop-change

then insert

#!/bin/sh 
USER="$3"
if [ "$USER" = "svnroot" ]; then exit 0; fi
echo "Only the svnroot user may change revision properties" >&2
exit 1

if you don't want to use a specific user, simply leave the svn pre-revprop-change hook empty.

#!/bin/sh

Enable the start-commit hook

vi minify/hooks/start-commit

then insert

#!/bin/sh 
USER="$2"
if [ "$USER" = "svnroot" ]; then exit 0; fi
echo "Only the svnroot user may commit new revisions" >&2
exit 1

if you don't want to use a specific user, simply leave the svn start-commit hook empty

#!/bin/sh

As you see, it's not 100% secure, it's only to prevent mistakes.

Give the execution right to both svn hooks

Otherwise you'll have a message like blocked by pre-revprop-change hook (exit code 255) with no output.

chmod +x minify/hooks/start-commit
chmod +x minify/hooks/pre-revprop-change

Init the synchronisation

We use svn over ssh, you can also use svn://, http:// whatever protocol you use usually.

Command usage is `svnsync init DEST_URL SOURCE_URL`

svnsync init svn+ssh://svnroot@svnserver.local/repos/minify http://minify.googlecode.com/svn

If everything is ok you'll see

Copied properties for revision 0.

You can check mirror repository by using command

svn proplist --revprop -r 0 -v svn+ssh://svnroot@svnserver.local/repos/minify
Unversioned properties on revision 0:
  svn:sync-from-uuid : c230a260-702f-0410-900f-efd535441baf
  svn:sync-last-merged-rev : 412
  svn:date : 2007-05-01T22:46:50.958069Z
  svn:sync-from-url : http://minify.googlecode.com/svn

svn:sync-last-merged-rev and svn:sync-from-url are ok

Synchronize the repository

Command usage is `svnsync sync DEST_URL`

svnsync sync svn+ssh://svnroot@svnserver.local/repos/minify

Every revision and properties from source repository will be mirrored.

Committed revision 1.
Copied properties for revision 1.
Transmitting file data ..
Committed revision 2.
Copied properties for revision 2.
Transmitting file data .

This could be long, very long, apache.org repository has more than 960 000 revisions, and svnsync must read each one.

If you want, you can stop the sync process, but you will have a sync-lock error message like :

Copied properties for revision 625.
Killed by signal 2.
svnsync: Caught signal
svnsync sync svn+ssh://svnroot@svnserver.local/repos/log4php
Failed to get lock on destination repos, currently held by 'svnserver.local:16655307-acde-47f1-b392-15e547cc99e1'
Failed to get lock on destination repos, currently held by 'svnserver.local:16655307-acde-47f1-b392-15e547cc99e1'

Execute this command to be able to resume the sync process

svn propdel svn:sync-lock --revprop -r 0  svn+ssh://svnroot@svnserver.local/repos/log4php

Use & update of the mirror

Now you can checkout and update from the mirror repository without dependence to original repository or network, remember no commit or properties change on the repository only svnsync.

Make manual svnsync or cron to keep the repository up to date.

Resources

http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt