Safe to share a Subversion working copy between OS?

Question

I've heard in the past that it's unsafe to share a Subversion working copy between OS.

E.g.:

1. copy a working copy from a Windows machine to a Linux machine, and use the Linux build of SVN on it.
2. On a Windows machine, access/manipulate an SVN working copy with both Windows binaries and CygWin binaries of SVN. (I might want to do this to use this solution for example).

But I haven't heard definitively whether it could cause corruption of the .svn data. It is true that EOL issues could be a problem if svn:eol-style is set to native.

What's the current status of this issue? Has it changed in more recent releases of SVN? Is it safe provided certain precautions are taken (e.g. not checking out/updating files with svn:eol-style=native on both platforms)?

Answer 1

My svn repository is on Linux. I have a working copy on Linux and another one on WindowXP.

On WindowXP, I use cygwin to access my working copy. Sometimes, I use also Tortoise to have a visual diff, a compplete history of a file...

I never try to restore ( or create form a backup) from a Linux repository created with svndump to a Window computer.

[EDIT]

I forgot to mention that update works perfectly with both working copy.

Answer 2

I've used svn on a shared network directory between unix, linux, solaris, and windows; anecdotally the only problem I ran into is that different svn client versions are 'incompatable'. The linux and unix machines were equiped with a version of svn older then the solaris svn; which was in turn older then the windows machine client. The result is that running 'svn up' updates the metadata files to whatever client is running; and the client won't access files with a more recent metadata version. Final end result being that svn clients should be kept at the same version number.

So, yes, I've been able to move a working directory around between machines with minimal loss of life. That said, I've never used any svn options beyond what was default.

Answer 3

From my experience, it works.

There are sometimes issues with case sensitivity between Windows and Linux though. Folders "Build" and "build" colliding and things like ".htaccess". But nothing hard to fix.

Answer 4

As CoderTao mentioned, using different versions of svn (client) on a working copy can cause silent WC format upgrades, so be sure to stick within a single version family to avoid that.

As an aside to your main question, I see you're working with a SVN repo across a slow link. You may want to look into Distributed source control systems which are designed for that sort of thing.

As an example, Bazaar (bazaar-vcs.org) has a bzr-svn plugin that will allow you to create a local branch of a remote SVN repo. You then have a fast local branch that you can check out into multiple locations, work on locally, diff, browse history, etc. You can commit locally and keep your separate local (Japan) branches in sync without slow commits to Australia. Once everything's good, you push your changes back upstream to SVN. There are lots of workflow example docs on the Bazaar wiki if you're interested. :)

Answer 5

Other answers aside (as they seem to suggest this is doable), I can report categorically that sharing a working copy (in our case via a Samba share) where we had "svn:eol-style native" in use did cause problems for us, and we try to avoid it.

If we needed to copy a working folder between machines (a more limited form of sharing, presumably as a one-time operation) we would expect to have to go in and perform CRLFTOLF conversions on all the svn:eol-style files, and in fact we've done that in the past by writing a utility to walk the tree, examining svn properties, and converting the files as required (all in Python).

So for the record, I'll state definitively that this is a problem.