kfogel@collab.net writes:
> So far I recall:
>
> 1. No change to the Subversion dist, but we write a FAQ item that
> explains the situation with ASP.NET and links to a simple patch
> that makes the client use "_svn" instead of ".svn". People who
> absolutely must can apply the patch. (If convenient for us, we
> can also link to a prebuilt Windows binary with this tweak, but
> that's optional -- no complaining if we don't do it :-) .)
PROS:
- ASP.NET users have a workaround for IIS: recompile with the
patch, or use a 'special' win32 client binary.
CONS:
- Every win32 client (svn, tortoisesvn, svnup, etc.),
must now publish 'special' ASP.NET binaries along side the
'normal' binaries.
- ASP.NET working copies become non-portable (unless Unix
clients temporarily set the runtime option, or unless a
rename script is run over the wc.)
>
> 2. The client automatically tries "_svn" if ".svn" can't be found.
> This is not completely trivial, as it also has to create new
> directories consistently, which means checking for a specific
> kind of error, etc... This option needs to be described in more
> detail.
This was Jack's original proposal: create '_svn' on win32, '.svn'
everywhere else, but always understand both.
PROS:
- ASP.NET users require no workarounds at all, and happily
interoperate with Unix.
CONS:
- libsvn_wc is now doing *two* disk stats to figure out if a
directory is under version control.
> 3. A configuration option (and/or command-line switch) to use
> "_svn" instead of ".svn". This is also non-trivial, since a
> baton holding this state has to make it down into the right
> parts of libsvn_wc. This is one method where having the patch
> in advance would be helpful. Perhaps there's a clean way to do
> it with a global, but in general we try to avoid globals...
PROS:
- ASP.NET users have a convenient workaround for IIS: just
set the runtime option.
CONS:
- ASP.NET working copies become non-portable (unless Unix
clients temporarily set the runtime option, or unless a
rename script is run over the wc.)
- converting the dirname from a compile-time variable to a
run-time is a bit of work. Not horrible, but not trivial either.
Yes, these are the same three options I've heard.
I vote for #2: I'm skeptical that the two disk stats will be
noticeable; I think that tiny 'con' *far* outweighs the convenience
of having a single codebase, single binary, and interoperability.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 26 18:18:13 2003