I'm casting a wide net here, looking for a solution to a problem many
users are going to have with Subversion's autoversioning features,
when 1.2 comes out.
Autoversioning is the feature whereby generic DAV clients (say,
Windows WebFolders) can drag files to and from a DAV share that is
backed by a Subversion repository. Dragging to the share results in a
commit, dragging from it works like a checkout.
Autoversioning is a Great Thing. It will expose many new users to
Subversion, in a simple and painless way, and make Subversion servers
that much more attractive to admins.
However, there is a fly in the ointment, a dragon in the meadow, a
shrubbery in the suitcase:
Transparent DAV filesharing doesn't work smoothly in Windows XP.
A detailed description of the problem is below. Anyone who knows
reliable workarounds, or has more information, please follow up to
this post. And let's please not get into "It's Microsoft's fault for
breaking an access syntax". That may be so, but the point here is to
find a solution. Recalling all copies of XP is not realistic :-).
The Problem:
============
Under Windows 98 and Windows 2000, accessing a DAV server via
WebFolders was simple: you typed in the URL, and everything worked.
Under XP, the situation changed. Microsoft decided that when the user
types a URL, what they really meant was a UNC path (something like
"\\server\share\path\...").
So WebFolders converts the URL to some analogous UNC path, then goes
off looking for that resource on the LAN. Of course, if the user
really meant a URL -- i.e, a true DAV server -- they're out of luck.
It doesn't matter whether the server is IIS or mod_dav under Apache,
because the server never even sees the request!
(Of course, if it's IIS, it might be serving the same resources on the
LAN via UNC paths, making it *look* like "IIS works, Apache doesn't".
But that's not really what's going on. No DAV server works, because
the client never even reaches the DAV server. If the IIS server were
remote and/or not accessible via UNC, it wouldn't work either.)
Solutions:
==========
There are workarounds for this problem, but they apparently differ
depending on XP servicepack combinations. We don't yet have a matrix
describing what workarounds work with what exact kinds of XP.
One workaround is to include a port number in the URL is enough to
suppress to the URL->UNC translation step, e.g.,
http://mydavserver.mycompany.com:80/path/to/dav/share/
In some flavors of XP, this is enough to suppress the URL->UNC
conversion and reach the DAV code buried in the bowels of WebFolders.
However, other flavors of XP will not be fooled, and will still
convert it to UNC.
Ben Collins-Sussman recalls hearing about another workaround, reported
to work on XP boxes where the port-number workaround didn't work, in
which one enters the URL in IE's File->Open box and gains access that
way. I haven't been able to dig up that URL yet, and I don't know
anything about the reliability/portability of that workaround.
The most reliable workaround currently known is to purchase WebDrive
($40 out of the box, site licenses also available), which simply takes
over from WebFolders and honors the DAV URLs the user enters. There's
also a free-as-in-beer product from Novell called NetDrive that does
the same thing, but apparently not as reliably. These workarounds
would presumably cover most or all XP variants, but of course
installing yet more new software to get autoversioning working would
cause a lot of grumbling.
Conclusion:
===========
We don't yet know whether this problem can be worked around in every
variant of XP that our users might run. Maybe there is a single
workaround that will solve this everywhere; or maybe each variant has
a workaround, but not the same workaround as other variants. It is
also possible that some variants simply have no workaround. Gulp.
So: if anyone knows something not mentioned above, please speak up!
References:
===========
http://blog.ianbicking.org/i-hate-web-folders.html
http://www.hss.caltech.edu/help/unix/admin/web/apache-webdav-xp
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 00:41:41 2005