.svn workaround?

James Bailey

unread,

Jul 1, 2004, 11:11:51 AM7/1/04

to

I use Subversion as my CVS and get an error while loading a web project with
the .svn folder in it. I know it's kind of been beaten to death, but is
there any workaround for this?

----
James Bailey

Gary Chang

unread,

Jul 1, 2004, 10:35:29 PM7/1/04

to

Hi Jame,

For the issues about using Subversion, I suggest you can also raise this
problem on IRC at irc.freenode.net, channel #svn and check their FAQ:
http://subversion.tigris.org/project_faq.html

Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Ian Rae

unread,

Jul 6, 2004, 10:32:33 AM7/6/04

to

"James Bailey" <ju...@junk.com> wrote in message news:<eosqD33X...@TK2MSFTNGP09.phx.gbl>...

The current workaround is for TortoiseSVN to have a special build that
uses "_svn" instead of ".svn". Look for the following on their web
page:

"Version 1.0.6.1200 for NT4/Win2k/XP (special version! We provide NO
support for this!) uses _svn folders instead of .svn to work around
the VS.NET bug with web projects. If you don't use web projects then
please use the official version. Note: working copies created by this
version are incompatible with other Subversion clients!"

Note. This is not a bug in ASP.NET as the TSVN FAQ claims. It's a
security fix in IIS that is not ever likely to be changed. See
http://www.contactor.se/~dast/svn/archive-2003-09/1352.shtml

--Ian

Appel

unread,

Jul 9, 2004, 5:28:01 AM7/9/04

to

I don't see how the subversion devs could change visual studio so that it can handle a legit folder name correctly. Or am I missing something here?

Adrian Weiler

unread,

Jul 26, 2004, 11:03:17 PM7/26/04

to

This is not a bug in IIS, neither version 5.1 nor 6, and this is not a bug in ASP.NET.
This is a bug in VisualStudio.

Proof:
(you don't need subversion to reproduce this, so please, Microsoft guys, just try it out).
For the following test, replace IIS with a slighly modified version the Cassini web server (available w/ source code from www.asp.net). The required modification is in ProcessDirectoryListingRequest() in Request.cs: comment out the three lines forbidding dots in file names. Rebuild and run Cassini, passing suitable values for physical and virtual path to match your web project.
You should be able to open your web project in VS.NET.
With your web project selected, click the "Refresh" button. This should work.

Using a command prompt, create a directory with a name starting with a dot inside your web folder, let's say mkdir .foo.
Verify that you can view that folder in the browser. If you applied the modification above, this should work nicely.

Now refresh the web project again: you will see that famous message "Unable to retrieve folder information from the server". Rename ".foo" to "#foo" (or whatever) and it will work again.

I made an additional test: I built Cassini in VisualStudio, and placed a break point in ProcessOneRequest() in Connection.cs. Verify that the breakpoint is hit when the web is accessed. Now refresh the web project in the IDE: the break point is NOT hit. So refreshing the project does not even involve a web server! This is entirely done in the local file system.

You may now safely forget about advices saying that this is because of a security fix in IIS. In the scenario above, no IIS is involved, so this cannot be a problem of IIS. At least not of IIS alone.

Conclusion: there is a problem in the VS.NET IDE. Please, Microsoft, recognize this. No, don't send me to the SVN FAQ. I already read all that stuff. There are no solutions to that problem, only workarounds. Its up to Microsoft to provide a real fix of the problem (or gimme the source and I'll fix it for you ;-).
No, renaming the directory is not an option. By the way, the SVN FAQ (http://subversion.tigris.org/project_faq.html#adm-dir) says: 'We recommend that you live with ".svn" if you possibly can. If you use some other name, your working copy may not work with Subversion clients other than the one you regularly use.'

Why is renaming the directory a problem? If you do this with one Subversion client, it will make the working copies incompatible with any other client, so you will have to change these too. To me, it makes sense to use several Subversion clients. I currently use: TortoiseSVN because to its nice integration in the Windows Explorer, RapidSVN as standalone executable for administrative tasks, PushOK's SVNProxy to integrate Subversion in the IDE, and I had also a try with AnkhSVN. I would have to change _all_ these, just because the IDE doesn't like files names starting with a dot. This is definitively the wrong way.

I (and probably many, many others) would be very happy if that issue could be solved at least with VS.NET 2005. I had a look what DEVENV.EXE is doing on the file system using FILEMON (from www.sysinternals.com): it examines every single directory in the web folder and looks for ASP.NET configuration files. The fix would so simple: instead of choking on file names starting with a dot, just ignore them.

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

Adrian Weiler

unread,

Jul 27, 2004, 12:44:44 PM7/27/04

to

Summary:
There is a problem with VS.NET when refreshing a web project (ASP.NET or Web Service) when using Subversion as Source Control. This problem is caused by the name (".svn") of the folder containing Subversion's administrative stuff. Currently, Microsoft does not assume a problem with one of their products, but up to now, the wrong product has been blamed to be responsible for the problem.

Claim:
This is not a bug or configuration problem in IIS, neither version 5.1 nor 6, and this is not a bug in ASP.NET. This is a bug in VisualStudio.