Eli : Memcached, MySQL, Highcharts

Tag - svn

Solve svn : Working copy is too old (format 10, created by Subversion 1.6)

Working copy is too old (format 10, created by Subversion 1.6) or (format 9, created by Subversion 1.5)

This message show up if your are trying to use Subversion 1.7 client with a Subversion 1.6 or Subversion 1.5 working copy.

Even if older clients and servers interoperate transparently with 1.7 servers and clients, when a working copy is upgraded to Subversion 1.7 new format, Subversion 1.6 and client can no longer be used on it.

You have two solution to solve this error :

  • Keep Subversion 1.7 client and upgrade the working copy to 1.7
  • Uninstall Subversion 1.7 client and downgrade working copy to 1.6 or 1.5


Upgrade to Subversion 1.7

Before upgrading to 1.7, a 1.6 client must be used to run svn cleanup on all working copies that require cleanup. Subversion 1.7 cannot upgrade corrupt 1.6 working copies.

Upgrade with Tortoise

Right-click on the working copy Folder, then click on "SVN Upgrade working copy" Upgrade_to_Subversion_1.7_with_Tortoise_1.png
Click on "Upgrade the working copy" on the next step Upgrade_to_Subversion_1.7_with_Tortoise_2.png This may take a while, but your working copy will be in Subversion 1.7 format.

Upgrade with command line client.

Simply use the new Subversion 1.7 command

svn upgrade

And your working copy will be in 1.7 format.

Downgrade the working copy

Use this guide to downgrade a Subversion working copy.
Remember that you can't downgrade a Subversion 1.7 Working Copy

Tuesday, October 5 2010

Solve svn : This client is too old to work with working copy error without upgrading Subversion

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.

Thursday, September 23 2010

Solving the revprop change blocked by pre-revprop-change hook (exit code 255) with no output error

What is the pre-revprop-change hook ?

The pre-revprop-change script is launched before any property is modified on the Subversion repository.

Because Subversion's revision properties are not versioned, making modifications will overwrite the previous value of that property and since data can be lost, Subversion supplies this hook to log changes or enable only some properties to be changed, ...

revprop change blocked by pre-revprop-change hook (exit code 255) with no output is a common error when playing with revision properties that can be solved in two simple steps.

Check the pre-revprop-change hook existence

By default, there only a template hook named pre-revprop-change.tmpl in the repository hooks folder.
You need a pre-revprop-change file, so you can rename it to only enable svn:log and svn:author (Commit log message & author) :

mv hooks/pre-revprop-change.tmpl hooks/pre-revprop-change

Or make your own hook to enable all properties to be changed :

vi hooks/pre-revprop-change

then insert

#!/bin/sh 
exit 0;

The exit 0; instruction is equivalent to a success for svn, so this one will allow EVERY revision properties on repository to be changed (Useful for svnsync).

Give the execution right to pre-revprop-change hook

It's a common mistake to forget enabling execution right to the hook

chmod +x hooks/pre-revprop-change

This is the second step, you are now able to change revision properties on your repository.

(exit code 1)

In case you obtain revprop change blocked by pre-revprop-change hook (exit code 1), this mean that pre-revprop-change hook is enabled, executable, but it does not allow you to modify the revision property you're trying to change.

Check the message it return (unless with no output is specified), check the hook code, if you can't or are not allowed to do theses things, check repository hosting documentation or contact your repository administrator.

Wednesday, May 12 2010

Using svnsync to mirror a google code repository

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