Subversion: Working copy is old development version

Question

I'm developing on OSX, and one of my Subversion working copies just started returning the following error for all commands, however my other checkouts work fine. I get the same message with both my Brew installed SVN binaries as well as my Cornerstone client, but other working directories are fine.

> svn update
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/working_directory' is an old development version (format 12); to upgrade it, use a format 18 client, then use 'tools/dev/wc-ng/bump-to-19.py', then use the current client
> svn upgrade
svn: E155019: Can't upgrade '/working_directory' as it is not a pre-1.7 working copy directory
svn: E150000: Missing default entry

I don't have the bump-to-19.py script anywhere on my computer (according to find / -type f -name bump-to-19.py), however I think I was able to find it on the Apache repository. That said, I am not familiar with what it does, or how to use it. Ideally I can avoid checking out a new version of this working directory and manually merging in all of my (many) changes.

The only info I was able to find is related to Netbeans and javahl, and I'm using neither.

EDIT: After downloading the bump-to-19.py file and making it executable, I tried it against my working directory to no avail:

> ./bump-to-19.py working_directory/
error: format is 29 not 18: 'working_directory/'

Answer 1

Although I was not able to figure out why my working directory was corrupted, I was able to work around it using rsync - there is an option, C, that will ignore CVS/SVN files and directories when making a backup. I made a backup using this option, checked out the project again, and then copied the backup back over the new working directory. SVN is happy again.

> rsync -arC working_directory working_directory_no_svn
> rm -rf working_directory
> svn co https://svn.example.com/project/trunk working_directory
> rsync -ar working_directory_no_svn working_directory

Answer 2

I had the same issue and here is how I resolved:

1. Delete the .svn folder at the top level (rm -rf .svn)
2. Checkout software again from SVN (svn co ...)
3. Good to go!

Answer 3

I know this has been around a while, but I found a solution using the hints given by SVN... Basically use the upgrade command as it states. Using CMD, I went to my workspace folder where the troubled project was located. Lets call the project Project1. You call the command:

"svn upgrade project1"

this resolved my issue the proper way without involving some sort of hack or workaround.

Answer 4

I had a similar issue, my svn is version 1.7.10, however my Subversion plugin for Eclipse is slightly older, I'm assuming 1.6.something.

Using the "rsync -arC working_directory archive_no_svn" command was a breakthrough - at least now I had a copy of the hours of synchronisation I had just completed.

I tried using the "svn co" but it was the wrong version, so I simply ran an update using the Subversion plugin within Eclipse - this restored the working directory from the repository - pretty much what I was after, and it was the correct version.

Getting the rsync back to the correct location was a trick. rsync appears to drop the working folder into the archive location, creating archive_location/working_directory/the-files. So syncing the archived data back into the working_directory was achieved with: rsync -ar archive_no_svn/working_directory .

Now I have to find out about upgrading my Subversion plugin for Eclipse to 1.7