Clearly, the ".svn" thing is causing a big problem for VS.NET users
(actually, I thought it was only ASP.NET, but I'm fuzzy on exactly
what each of these terms encompasses, so forgive me if I blunder).
For those who don't already know, the problem is that in {VS,ASP}.NET,
you can't use "." to start a directory name. This is Microsoft's bug,
but we still have to live with it. The workaround has been for
victims to apply this patch and rebuild:
Index: subversion/include/svn_wc.h
===================================================================
--- subversion/include/svn_wc.h (revision 8945)
+++ subversion/include/svn_wc.h (working copy)
@@ -714,5 +714,5 @@
* matter of public record.
*/
-#define SVN_WC_ADM_DIR_NAME ".svn"
+#define SVN_WC_ADM_DIR_NAME "_svn"
But that's inconvenient. People getting binary packages may never
have built Subversion before, nor should they have to.
If I recall correctly, two kinds of permanent solutions have been
discussed:
1) Add a configuration option that says whether to look for ".svn"
or "_svn". It's up to the user to set this option.
2) Make Subversion smarter -- so smart that it knows to try looking
for ".svn" first and then "_svn" if that fails. No new config
option, no new user training required. Everything Just Works.
Although (2) is nicer in theory, I think I prefer (1). It's a lot
easier to code, because there are many places where we construct a
long path involving SVN_WC_ADM_DIR_NAME, and then use the path much
later. The path constructor does not even look at disk; it just
manipulates path components. So we'd only get the error well after
the path had been constructed.
Another factor: eventually Microsoft will probably fix this bug, at
which time we'll be sorry we changed logic throughout libsvn_wc
instead of just making one startup-time decision based on a
configuration set by the user.
Of course, Subversion could also try to notice what kind of working
copy it's operating on and pick a style at startup time, but that
falls down if a working copy contains both kinds of names. Solution
(1) also falls down in that circumstance, but the point is that users
will already be aware of the problem, because they had to set the
config variable, so they'll be mentally prepared for weirdness.
This ties in with the Non-Mystery Factor: it's better to make a
user-visible change, where we get to put a comment in the config file
and explain why we're doing it, so people are aware that there is an
external limitation whose solution is a workaround. It would do more
harm than good for Subversion to try and silently solve the problem,
because then its behavior would be less predictable. (This is similar
to The Principle of Least Surprise, I guess.)
So: It would be nice to fix this, and my preference is solution (1).
I'll happily abandon that preference in favor of anything that's been
thought out more thoroughly. Fire away :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 9 00:46:28 2004