John Peacock <jpeacock@rowman.com> writes:
> Show us a patch, then. I'm not in any position to set policy, but I
> can pretty much guarantee that _not_ providing even a proposed
> implementation is going to mean you'll _never_ get an answer. Either
> it's as simple as some people think, or it is a complete rewrite of
> large portions of code. Until that becomes clear, it is complete
> speculation as to whether/when to apply the patch.
>
> If you care enough about this feature, and have the ability to write
> the code, then write the code. Saying you would have done it in May
> if someone said it would be accepted is a cop out. Without code, it
> cannot be accepted, end of discussion.
Wait a second, John. I think David's point is quite good, and not a
"cop out" at all.
Describing a solution is generally easier than writing a patch, and a
precise description is usually enough basis for discussion. We don't
actually need to see the code that would cause Subversion to (say) try
".svn" first and then fall back to "_svn", or whatever. A detailed
description of the proposed feature is sufficient for us to discuss
whether or not it would be accepted as a patch if one were submitted.
It's quite natural that someone would want to settle that question
*before* investing the time to implement the patch, I think!
What would help now is if someone could take the time to summarize all
the proposed solutions in one mail, so people can probe and fill in
the details for those that are not specified completely enough.
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
Received on Fri Sep 26 18:07:52 2003