It's possible some people might have misunderstood my proposal.
I wasn't proposing a "configure time" option to use '_svn' instead of
'.svn'. I was proposing a run-time option in ~/.subversion/config.
Big difference! Maybe this will deconfuse some of the discussion.
-Karl
Ben Reser <ben@reser.org> writes:
> * 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 10 00:43:24 2004