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

[Guido Leenders]

Hi,

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>

Linux:
=====
$ 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.

Regards,

Guido

[Andy Levy]

On Sat, Nov 17, 2012 at 3:41 AM, Guido Leenders <Guido.L...@invantive.com> wrote:

Hi,

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).

This is an unsupported and not-at-all recommended or encouraged scenario. If it worked in the past, you were fortunate; no guarantees were ever made that it would work, so breakage should not be unexpected.

Never share working copies between OSes or users. Best practice has always been one WC per OS per user.

There is no way to "overcome this" aside from stopping the activity altogether.

[Guido Leenders]

Hi Andy, thanks for your feedback. Obviously my problem is not a bug, but unsupported use and a little weird error.

 

Is it a good suggestion to change the working copy format to include some type of “supported platform and user”, just as it already does check on the version of the repository? This ensures that users such as me and my collegeaus can only use the software in a supported way. This reduces the risk of data corruption.

 

Regards,

 

Guido

--

[Ben Fritz]

On Sat, Nov 17, 2012 at 6:25 AM, Andy Levy <andy...@gmail.com> wrote:
>
>
>
> On Sat, Nov 17, 2012 at 3:41 AM, Guido Leenders
> <Guido.L...@invantive.com> wrote:
>>
>> Hi,
>>
>> 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.
>
>

> This is an unsupported and not-at-all recommended or encouraged scenario. If
> it worked in the past, you were fortunate; no guarantees were ever made that
> it would work, so breakage should not be unexpected.
>
> Never share working copies between OSes or users. Best practice has always
> been one WC per OS per user.
>
> There is no way to "overcome this" aside from stopping the activity
> altogether.
>

If this is a misuse, it is a quite common misuse. A quick google
search turned up:

http://stackoverflow.com/questions/3109939/moving-svn-working-copy-to-another-computer
http://stackoverflow.com/questions/493820/how-do-i-copy-my-entire-working-copy-between-hard-drives
http://stackoverflow.com/questions/1061383/safe-to-share-a-subversion-working-copy-between-os

I've always had the impression, which I've shared with others, that an
SVN working copy is just a set of files you can copy around and access
from multiple systems like any other set of files.

Other revision control systems work certainly don't complain if you
use the same client version to interact with the some working copy on
two different OSes. SVN doesn't normally, either.

I understand that this particular case is from a user using two
DIFFERENT versions of SVN, but it is VERY unexpected that the SAME
version would cause problems. That's like opening a jpeg in an image
editor on Linux and getting errors when opening the same jpeg in the
same program on Windows.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029512

To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].

[Ben Johnson]

Without knowing anything about the underlying structure of a working
copy, I would actually agree with original poster that a) this is a
desirable behavior (feature) and b) this somehow feels like an
"expected" feature in an SVN client.

As someone who switches between operating systems routinely, I would
hope and expect that my working copies are usable from within either OS,
and with any SVN client. Like the OP, I have done this in the past, and
without issue (to my knowledge).

That said, my experience has been that the SVN developers don't
undertake an action unless the rationale is sound (or well-intentioned,
at the least). So, I'm sure there is a good reason that we shouldn't
expect this capability.

Would anyone with the technical background to comment be willing to walk
us through why cross-OS working copies are not possible and should not
be expected?

I'm not trying to sound ungrateful; I just need to set expectations
reasonably (for myself, and for those who depend on my advice).

Thank you,

-Ben

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029516

[Guido Leenders]

Regarding: "I understand that this particular case is from a user using two DIFFERENT versions of SVN, but it is VERY unexpected that the SAME version would cause problems"

I am sorry to have created confusion. Therefore some extra information.

We are using the SAME version of SVN, but for a different platform.

The TortoiseSVN version 1.7.10 listed provides no additional technical information; it is just there to illustrate that TortoiseSVN users will experience this problem even when carefully matching the command line versions.

The problem also occurs when using the svn 1.7.7 command line client on Linux and Windows.

Regards,

Guido

-----Original Message-----
From: Ben Johnson [mailto:b...@indietorrent.org]
Sent: Tuesday, November 20, 2012 2:12 AM
To: us...@tortoisesvn.tigris.org
Subject: Re: Working copy corruptions due to dual use of SVN on Linux and Windows against same working copy

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029596

[Oto BREZINA]

This question is more for svn mailing list.

Without going to deep in details (which I don't know anyway) I'll share
my understanding.

1.6 was file based WC making it easy to copy and share - not really safe
through.

1.7 is DB based. Do you expect you DB. (e.g. MySQL) databases data can
be safely read from multiple platform, or even same platform in multiple
instances?
It may but it is not recommended.
When switching OS/or user many states may be unhandled, rights may get
wrong ...
DB versions may not match, have different int size, or have whats ever
difference.

You are free to try but was informed that it is not supported - tested,
was not intend to make it work - so don't be surprised.
Actually I'm sharing my WC via samba between Linux and Windows (both
ways) quite happily, but once my WC get corrupted or start to complain
something, I'll know that's my problem ...

--
Oto ot(ik) BREZINA

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029605

[Simon Large]

Exactly. The versioned files themselves are usable on both platforms
and as long as you use the same SVN client all the time it will work
fine. What is not supported is using a Linux client and a Windows
client on the same working copy for the reasons Oto explains.

Simon

--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029640

[Niemann, Hartmut]

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
IC RL LOC EN LE 8
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264
Fax: +49 9131 7-26254
mailto:hartmut...@siemens.com

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.L...@invantive.com]
Gesendet: Samstag, 17. November 2012 09:41
An: us...@tortoisesvn.tigris.org
Betreff: Working copy corruptions due to dual use of SVN on Linux and Windows against same working copy

[Guido Leenders]

Thanks for the tip.

 

I have checked the wc.db versions as follows:

 

Svn checkout on Windows, look at byte 96…99 according to the file format. Version = 3.7.12.

 

Svn checkout of same project from Linux, strangely enough the bytes 96..99 are all 0. Instead checked search path. Sqlite version = 3.6.20.

 

So there is a version difference indeed. Now I have learnt that the sqlite libraries obviously can not handle a database well when running cross versions. According to SQLite itself it uses a single cross-platform file (locking entire database during writing and allows multiple readers).

 

I will try aligning the sqlite version on Linux with the one of Windows which is an unsupported but for our purposes helpful configuration.

 

To improve usability I would find it helpful that SVN would complain when the database files had been created by a different (incompatible) version. I know now the problem, but for first time users a good error message would help.

 

Regards,

Guido

[David Balažic]

A line or two in the code that checks the version and drops out with an error message* would save a lot of user trouble and developer time (as mail threads like this one etc.).


* - like "Incompatible sqlite db, not opening to prevent possible corruption"

Regards,

David Balažic
Software Engineer
www.comtrade.com




________________________________

From: Guido Leenders [mailto:Guido.L...@invantive.com]
Sent: Tuesday, November 20, 2012 11:15 AM
To: us...@tortoisesvn.tigris.org
Subject: RE: Working copy corruptions due to dual use of SVN on Linux and Windows against same working copy
Importance: Low



Thanks for the tip.



I have checked the wc.db versions as follows:

Svn checkout on Windows, look at byte 96.99 according to the file format. Version = 3.7.12.

URL: http://svn.invantive.com/repos/p104/trunk/build.xml <http://svn.invantive.com/repos/p104/trunk/build.xml>
Repository Root: http://svn.invantive.com/repos/p104 <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.

Regards,

Guido

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029668

[Ben Fritz]

On Tue, Nov 20, 2012 at 2:02 AM, Oto BREZINA <ot...@printflow.eu> wrote:
>
> 1.6 was file based WC making it easy to copy and share - not really safe
> through.
>
> 1.7 is DB based. Do you expect you DB. (e.g. MySQL) databases data can
> be safely read from multiple platform, or even same platform in multiple
> instances?
> It may but it is not recommended.
> When switching OS/or user many states may be unhandled, rights may get
> wrong ...
> DB versions may not match, have different int size, or have whats ever
> difference.
>
> You are free to try but was informed that it is not supported - tested,
> was not intend to make it work - so don't be surprised.

This may be true, there may be implementation decisions made that
prevent using a working copy from one system on another. But if this
is the case, I think this is a bad design decision; or at the very
least, bad documentation. Consider a person who keeps a working copy
on a thumb drive to cart around with them to whatever computer they
happen to be working on. Shouldn't they be able to commit, update,
whatever, on any of these systems, as long as a compatible version of
SVN is installed? At the very least, the fact that SVN does not
operate well across OSes should be documented. Using git or Hg, for
example, I would certainly expect this to Just Work, I see no reason
why SVN should be different in this regard. A program should be able
to read and write its own data regardless of where the program was
running at the time the data was created.

I have noticed some quirks when working between OSes on the same WC,
but they are little things like the Windows SVN not being able to set
the execute bit when the SVN properties say it should be set. I expect
things like that. WC corruption would be totally unexpected to
basically anybody I think. I don't think you can fairly call it user
error when the user was never warned not to do that.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029757

[Simon Large]

You're barking up the wrong tree here. The WC handling is done
entirely by the subversion library, not by TortoiseSVN. You really
need to take this argument to the subversion users mailing list.

Simon

--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net

------------------------------------------------------

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029774

[Wayne Johnson]

>
> This may be true, there may be implementation decisions made that
> prevent using a working copy from one system on another. But if this is
> the case, I think this is a bad design decision; or at the very least,
> bad documentation. Consider a person who keeps a working copy on a
> thumb drive to cart around with them to whatever computer they happen
> to be working on. Shouldn't they be able to commit, update, whatever,
> on any of these systems, as long as a compatible version of SVN is
> installed? At the very least, the fact that SVN does not operate well
> across OSes should be documented. Using git or Hg, for example, I would
> certainly expect this to Just Work, I see no reason why SVN should be
> different in this regard. A program should be able to read and write
> its own data regardless of where the program was running at the time
> the data was created.

This is more than just an issue of how the code is written. You also have
to take into account how the code is built. Further there are things you
can do with a Linux file system that cannot be done (or is done very
differently) than a Windows file systems.

So, I think it would be unreasonable to expect a tool built by Bob for
windows and the same tool built by Jack for Linux to necessarily play nice
together since we don't even know of the same build options were used for
all the libraries used by the tools.

Finally, there are configuration options that can be set in subversion
that will create confusions if used from multiple OS's. Setting line
endings to OS default comes to mind. There may be others.

To complicate the matter the original poster was using TSVN on a Samba
share. This pulls in another set of build/configuration issues that must
be handled by the user.

That's not to say that there aren't things that the SVN devs can do to
make this better or worse. It just to point out that even if they did
everything possible it still won't solve the problem 100% (assuming they
don't do the official releases.) Also keep in mind that they are in the
same boat as the rest of us. They have features and bugs to fix and they
have to decide which ones are more important.

Wayne

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3029790