Re: .svn vs _svn on VS.NET (ASP.NET)

On Tue, Mar 09, 2004 at 07:55:07PM +0000, Barry Scott wrote:
> Does it work to make the value of SVN_WC_ADM_DIR_NAME be platform specific?
> Windows uses "_svn" the rest uses ".svn". (I'm assuming Mac OS X is
> happy with .svn).

This is specifically what we're trying to avoid. We'd either end up
doing one of two things:

* Always set windows to use _svn. Which we don't want to do because it
forces all the Windows users to be icompatable with other platforms,
when they may not be affected by the problem.

* Make _svn a configure time option. But then we're back to these
specific users having to build subversion. If we post binaries with
_svn only then the net effect for binary package users is the same as
the above option. We could ship two versions of the binaries but
they'll be incompatable and confusing to end users.

I think our best bet is to add a configure option for Windows users.
Ship binaries with .svn as the default. Users/shops with the problem
will have to rebuild with the configure option. These shops can
standardize on the _svn and go from there.

Neither of these changes can be made in a patch release. Because it
would mean a change to the working copy formats that is not backward
compatable.

It's unclear if we can really call it forward comptable if all clients
can't read both. Which brings us back around to the determining the
name at runtime problem.

We either have to punt this until 2.0 or fudge on our compatability
guarantees IMHO.

> I think with my pysvn hat on I don't care what the value is as I
> call an svn API function to know if I'm looking at a wc dir that
> has an admin dir.

I don't think anyone except the client lib is using this constant. But
since we included it in our public interface we can't count on that and
is covered by our compatability guarantee.

-- 
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