[Out of lurker mode]
I've been evaluating SVN for a while, considering whether it will work
for our organization. We're preparing to begin working with ASP.NET in
the near future, so this issue has grabbed my attention. I'd like to
provide some observations, and some commentary.
My observations:
1) As a "correctness" issue, I can see a point about having a file
without a filename, only an extension. True, that's only the way Windows
interprets it, but that seems just as valid an arbitrary interpretation
as to treat the leading dot as a hidden attribute. Anyway, someone
suggested that .svn.svn or such like (I prefer .meta.svn - I think it
explains what it is) could be "more correct". OTOH, it is unclear
whether this change will address the symptoms in ASP.NET
2) When we're considering how many potential users out there will be
inconvenienced by this solution or that solution, I would imagine that
those developing ASP.NET solutions are far less likely to be sharing
their working copies across platforms. Then again, I may be wrong. Also,
it appears to be a significant problem only to those working against
remote servers, since a workable alternative is to tell VS.NET that the
project is a "Local" project.
3) If the issue isn't addressed in version 1.0, that doesn't mean that
it can't be addressed in version 1.5, or 1.1, or 1.0.1. We just need to
make sure that whatever choice we make in 1.0 doesn't make it unduly
difficult to make the next choice. So maybe the ASP.NET users will have
to deal with unofficial patched binaries for a couple of months or so
after the general availablility.
My commentary:
a) Yeah, I want a subversion release that fully supports ASP.NET, in
spite of its, uh, let's call them "quirks." But as long as 1.0 doesn't
cement choices that make it difficult to reach that goal, I say let the
core developers move on and get this thing golden. Personally, I think I
can deal with the cons of option #1 for a limited time while the
community finds the best long-term solution.
b) Even if switching to .meta.svn, or something like that doesn't fix
the root problem that started this thread, I think we'd find ourselves
in a more defensible position for the future if the finger of blame
can't come back pointing to us saying, "Well duh, you didn't give it a
file name." I guess, I'm just hoping that before we cement things, we
could consider a filename like this one to avoid similar quandaries in
the future.
[back to lurker mode]
Steve Dwire, Sr. Technical Architect
Park City Solutions - (iServices)
-----Original Message-----
From: kfogel@collab.net [mailto:kfogel@collab.net]
[...]
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 :-) .)
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.
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...
Are there others? I don't know; I'm just speaking off the top of my
head here.
Someone who really wants this problem solved could start keeping track
of all the solutions, maintain lists of pros/cons associated with
each, and keep a concise summary in front of the list so people can
focus & compare.
I'm in favor of option #1 myself. It's the simplest workaround from a
development point of view, and until we have a better sense of how
many people are being inconvenienced, we should optimize for developer
time.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 26 21:22:56 2003