[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A proposed solution for svn admin directory names

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-06-29 18:26:21 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> On Jun 29, 2005, at 10:51 AM, Jonathan Malek wrote:
> >
> > #define SVN_WC_ADM_DIR_NAME ( ( getenv( "SVN_ADM_DIR") ) ? ( getenv(
> > "SVN_ADM_DIR") ) : (".svn") )
> >
> > Thanks for taking the time to look at this Ben--I know it's been
> > hashed and rehashed, but I think this is a simple solution that works.
> The 'cons' of this proposal previously were based on the assumption
> that making the value of SVN_ADM_DIR into a runtime option would have
> involved using ~/.subversion/config, which would have been a huge
> coding change. But now it seems like a tweak to the already existing
> #define will accomplish the same task.
> The only other 'con' listed was that ASP.NET working copies would be
> non-portable. But frankly, that's the world we already live in.
> There are already lots of shops out there using 'special' TortoiseSVN
> builds which use '_svn' directories. So from where I stand, this
> proposal seems like a net gain. Nothing gets any worse, but it means
> Tortoise can stop making special releases.
> IANTSP -- "I am not the subversion project". Do any other developers
> have opinions about this?

  * What the performance penalties of calling getenv() as many times
    as it would be called by our already-slow libsvn_wc

  * Of all the forms of runtime configurability, I'm a little bothered
    that this one chooses one of least predictable/hardest to debug
    ones available. Subversion runs its own hooks and such with
    basically clean environments, which has caused a number of folks
    to stumble over hooks that don't seem to work. Now, hooks might
    not often do working copy operations -- I brought that up solely
    because it illustrates (I think) how precarious the use of
    environment variables can be. I know the .subversion/config thing
    was a huge coding change, but frankly I think it's a far better

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 18:30:40 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.