[BUG] The client can't use a different directory than .svn
From: Philippe Lavoie <philippe.lavoie_at_cactus.ca>
Date: 2003-12-04 20:27:32 CET
I've browed the archive a bit and the issue has been raised a couple of times already and I'd like to raise it again. As some of you know IIS has some quirks. One of them is that it can't cope with a file which is only an extension, i.e. .svn.
This means that any development of a web application causes errors from Visual Studio .NET (and older versions too). This is really dumb on IIS's part, but it might never be fixed by Microsoft. Therefore, I would hope that perhaps subversion could be told to use another directory.
Somebody said that a potential solution would be that for now, in a Windows world svn would be used and in unix .svn. That solution has the advantage of being easy to implement in the short term. Somebody also said that if somebody really cared about this, they'd generate a patch for it...
I really care about this as otherwise subversion will never be approved by our company as an 'accepted' tool. So here is a patch for this. Somepeople raised the concern that people wouldn't be able to just drop a working copy from unix onto windows, well it's true for more than just the .svn vs svn reason. The end of line character can really cause headaches when you go from one system to the other. You are better off creating a working branch and doing updates from one system to the other (my 2 cents).
Anyway, here is the patch. Inside include/svn_wc.h
At the line 692 replace
#define SVN_WC_ADM_DIR_NAME ".svn"
Inside configure.in add
The above would be so the .pl and .py know what to look for. I'm unfortunately not adept enough to figure out whether your are on a windows machine or not from a configure file. Check if something like this compiles ?
Some documentation change will be required, i.e. either add (svn under windows) after every mention of .svn or add a global notice or use variable substitution inside the documentation by adding a lot of .in files.
I'm not on the list, but please include me in the correspondence regarding this issue. In particular, if you need me to go through all the documentation before you approve this, I'll do it. SourceSafe is such a pain and CVS is showing its age.
This is an archived mail posted to the Subversion Dev mailing list.