On Mon, Mar 08, 2004 at 04:39:44PM -0600, kfogel@collab.net wrote:
> 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).
I don't buy this. I think there's been very few people who have
actually said this problem is affecting them. I think there are a lot
of people saying this should be fixed, many of whom are admitting it's
not a problem they've encountered yet. In fact many of the people
arguing for it aren't even clear on what the problem is.
Before we decide to do something about this. I'd like to have a better
understanding of just how many people are actually having this problem,
or haven't adopted subversion because of this problem.
> 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.
I don't see a way to do either of these changes before 2.0. They force
an API change that there is no good way to deal with backwards
compatibility. SVN_WC_ADM_DIR_NAME is exported in our public API. You
can't easily replace a constant in the API with something determined at
runtime.
We can't change it to a global variable. That's something we've avoided
entirely due to thread safety issues and ugliness. And there's always
the possibility that an app will want to work on a working copy with one
style in one thread while with another style in another thread. We do
allow apps to change the configuration themselves.
You can't replace it with a function call because without an app passing
a context/baton in there's no way to figure out what to return except to
end up with a global variable.
Not to mention that both a variable and a function call are
syntactically incompatible with ways you can use a string constant.
I frankly can't see anyway to deal with this within our compatibility
guarantees without doing a 2.0 release.
I think it's pretty clear that we've got changes we want to make to the
wc library anyway. Pretty major issues. So if we can't do it until 2.0
then what's the point of even thinking about it now. We've got an issue
on it. It should be taken into consideration when the redesign happens.
In short I think this is something we're looking at being able to do
many months away from now. We don't know what the situation will be
with this bug on Windows by then. We don't know what our working copy
design will be like by then. Let's put our effort into issues that are
higher priorities and that can be done within the 1.x releases.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 02:26:06 2004