On Feb 13, 2010, at 10:11, Tyler Roscoe wrote:

> I can't find it right now but there was a presentation about the top ten
> ways *not* to use Subvesion. One of the entries was about using
> Subversion in a way that it was not designed to be used.  This arises
> most frequently when people want to use Subversion as a backup
> mechanism, but I think it applies equally to your desire to use a single
> working copy across platforms no matter the cost.

In my experience, sharing a working copy between OSes can work, if you're aware 
of the limitations. These include:

Checking out files with eol-style:native will give them the native line ending 
style matching the client that did the "svn checkout". I am not certain what 
happens with "svn update" later: do files get the eol-style of the client 
currently doing the update or of the client that originally did the checkout? 
The latter would mean that the native eol-style was stored somewhere in the 
.svn directories by the client that did the svn checkout. To discover if this 
is the case, you could check out a working copy on UNIX and check out a working 
copy from the same URL on Windows and then diff them. If they differ, you may 
be able to use that information to patch the contents of the .svn directories 
on your UNIX box on the SMB share, in addition to running a tool like unix2dos 
or ux2dos to fix the line endings in the actual files. However, this advice 
will get me yelled at by the list, because we cannot recommend modifying the 
contents of the .svn directories manually for any reason. So I'm merely saying 
you could do this; I'm not recommending you do this.

Symlinks don't work on Windows. If you check out a working copy on Windows that 
would contain symlinks on UNIX, you'll instead get a text file, whose contents 
is "link " followed by the path to the original item. If you check out on UNIX, 
you get a symlink. If you check out on UNIX on an SMB share that's hosted on 
Windows, I'm not sure what you get. Best advice is not to have any symlinks in 
your repository if you are going to be checking out on Windows ever.

Windows and Mac filesystems are by default case-insensitive; UNIX filesystems 
are usually case-sensitive. If you need to use your repository from Windows or 
Mac clients, you will want to not commit files to the repository whose names 
differ only in case. There is a pre-commit hook in the Subversion source 
distribution that you can install that prevents such things from happening.

Windows has several restrictions on the names files can have, which are listed 
in this Wikipedia article:

http://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words

You can commit files with these names on UNIX, but trying to move these to 
Windows will give you a cryptic error. So you should not commit files with 
these names to the repository. You could write a pre-commit hook to prevent the 
commit of such files if you believe this will be a frequent problem.


Reply via email to