[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: Working copy corruptions due to dual use of SVN on Linux and Windows against same working copy

From: Niemann, Hartmut <hartmut.niemann_at_siemens.com>
Date: Tue, 20 Nov 2012 10:27:58 +0100

Hello Guido!

The key change in SVN 1.7 is the .svn reorganisation using a sqlite database.
So if the versions of the sqlite libraries differ, that might make the working copys icompatible
and that would explain the message you got from windows.
Maybe you can force your linux system to use the exact same sqlite library version tortoiseSVN uses on windows.
Maybe you can open the wc.db database with sqlite3(.exe) on linux and windows and see whether it looks the same on both sides?

Just a guess.

Mit freundlichen Gr√ľ√Ÿen
Dr. Hartmut Niemann

Siemens AG
Infrastructure & Cities Sector
Rail Systems Division
Locomotives and Components
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264
Fax: +49 9131 7-26254

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter L√∂scher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael S√ľ√Ÿ; Sitz der Gesellschaft: Berlin und M√ľnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M√ľnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322

Von: Guido Leenders [mailto:Guido.Leenders_at_invantive.com]
Gesendet: Samstag, 17. November 2012 09:41
An: users_at_tortoisesvn.tigris.org
Betreff: Working copy corruptions due to dual use of SVN on Linux and Windows against same working copy


We are using SVN 1.7.7 (TortoiseSVN 1.7.10) on Windows and SVN 1.7.7 on Linux with Samba against the same working copies. The working copies are located on the home directory of the user (/home/XXX or h:\).

Reason for such dual use is that some build software runs only on Windows and some only on Linux and there are no really reliable platform crossing mechanisms.

This worked fine with SVN 1.6, but since a few weeks we are working with 1.7. We have tested 1.7 in our setup for months on a Windows only laptop and working copies had little to no problems.

Since we started using dual use of the working copies, we are frequently and consistenly having working copy issues. It seems that either Windows or Linux changes something, probably in the .svn folder, that causes the other side to complain. If you stick to Windows only Tortoise or Linux only Tortoise it works fine. But for several operations that is not practically feasible (Linux side scripting, but users on Windows which do not all know all complex SVN command line arguments).

Sample of errors:

Windows (with commandline here):
PS H:\ws\p104> svn info .\build.xml
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy 'H:\ws\p104' 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 PS H:\ws\p104>

$ svn info build.xml
Path: build.xml
Name: build.xml
Working Copy Root Path: /home/smoke/ws/p104
URL: http://svn.invantive.com/repos/p104/trunk/build.xml
Repository Root: http://svn.invantive.com/repos/p104
Repository UUID: c849056f-1cdd-4f09-aa32-1c9aa175cbcf
Revision: 20444
Node Kind: file
Schedule: normal
Last Changed Author: smoke
Last Changed Rev: 20444
Last Changed Date: 2012-11-14 23:47:24 +0100 (Wed, 14 Nov 2012) Text Last Updated: 2012-11-14 23:47:25 +0100 (Wed, 14 Nov 2012)
Checksum: 8f216a7b6bf719ad5201948f8209399ab00d1a87

Any suggestions how to overcome this? I had expected that if you stick to exactly the same SVN version on both sides, we could further continue our dual use.




To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-11-20 10:28:09 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.