As promised, I did look into this again on Monday. I haven't had a chance
to type up the results of looking into it again until now.
I'm going to present the results in a Q&A type format.
Q: When does this problem occur?
A: When developing asp.net projects using Visual Studio.NET, and subversion.
ASP.NET is a way of developing websites that have code which runs on the
server. Only ASP.net is affected by this, so people developing any other
type of project should have no problems using svn.
Q: What causes the problem?
A: ASP.net projects are stored on a (possibly) remote machine, and accessed
by visual studio using Front Page Server Extensions. There is a bug
somewhere in this dealing with path names that begin with a leading '.'.
Q: What investigation has been done before?
A: I pointed a friend on the ASP.net team to a newsgroup post about this a
while ago, and he told me that he thought it was a bug in FPSE, which I
don't have a hope of getting fixed.
Note that I did say it should be fixed in Whidbey for local filesystem
websites (which are a new Whidbey feature), because they don't use FPSE.
However, Whidbey will still allow ASP.NET projects to work against either
local or remote IIS installations using FPSE. I expected the bug would
still be present in those scenarios until FPSE fixed it.
Q: What did you do on Monday?
A: I installed Everett on a Windows XP machine, and Whidbey on a Windows
Server 2003 machine. Then I verified that the bug existed in Everett (not
with svn, just with a folder named .foo). Next I did some research about
Parent Path and URLScan, and found that they won't fix the problem). Then I
created a local filesystem website using Whidbey, and created a folder named
.foo. This worked fine. Next I created a local IIS website using Whidbey,
and created a .foo folder there. This worked fine too. Finally I created a
Remote IIS website using FPSE (the site was hosted on the XP machine with
Everett). I created a .foo folder, and everything still worked fine. At
that point I realized that the bug wasn't in FPSE, but was instead in Visual
Studio's code which talked to FPSE, so I emailed my friend on the ASP.net
team and asked him to take another look.
He said he will take a look, but it's currently a lower priority for him
then getting ready for the Whidbey beta, so I don't know when I'll have more
info.
Q: What can we do now?
A: There are a several options. 1. Wait for Whidbey, which has the problem
fixed. 2. I will try to make sure the issue is considered for any service
packs that may be released for either VS.NET 2002, or 2003(Everett). 3. If
anyone has a support contract for Visual Studio, they can try talking to PSS
and getting the issue escalated and a QFE(hotfix) issued for it. Pushes for
QFE's have to come from customers and PSS, so I can't really push this
approach.
Q: What about parent path and URLScan?
A: Parent path only affects actual Parent paths, (..) not things that have .
in the name. Urlscan can't solve the problem for at least one and possibly
two reasons. First, FPSE is a high priority ISAPI filter, which means it
sees the paths before URLScan. Second, the bug doesn't appear to be in
FPSE, but rather in the ASP.net project system, so I don't think it would
have any effect even if FPSE was a low priority filter.
Q: What do you think should be done about the problem?
A: Since it will be fixed in Whidbey (and possibly in Everett and 2002), I
think svn should do nothing, and continue recommending people use a custom
built client for now.
Hope that clears things up a little bit.
--
Kevin Pilch-Bisson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 19 04:13:04 2004