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

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

From: Ben Johnson <ben_at_indietorrent.org>
Date: Mon, 19 Nov 2012 20:12:21 -0500

On 11/19/2012 7:35 PM, Ben Fritz wrote:
> On Sat, Nov 17, 2012 at 6:25 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
>>
>>
>>
>> On Sat, Nov 17, 2012 at 3:41 AM, Guido Leenders
>> <Guido.Leenders_at_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.

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-11-20 02:12:41 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.