Extending SVN_ASP_DOT_NET_HACK

["Doyle, Patrick" <WP...@dtccom.com>]

I see that SVN_ASP_DOT_NET_HACK is only enabled for Windows platforms.
(And, given the use case it is targetted at, that is understandable.)  I
also see that, as it is implemented now, it allows for only one of two
possible administrative directory names, ".svn" and "_svn".  There is a
comment in the code that the name must point to a statically allocated
string constant to avoid potential pool lifetime issues.  

I would like to extend this capability to allow for an arbitrary
administrative directory name specified by an environment variable,
certainly for my own purposes, but possibly others would find this useful as
well.

So, I have 2 questions:
1) Where can I find out more information about the thought process that went
into SVN_ASP_DOT_NET_HACK?  I've tried search the issues database, and
googling it in general, but haven't been able to find anything of substance.

2) What happens to the pool management if there is a pointer to a string
stored in the process's environment space?  I suppose, on some processors,
with some OS's, this may not be distinguishable from malloc()'d memory.  But
I don't know that for certain.

Any thoughts?

--wpd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Extending SVN_ASP_DOT_NET_HACK

[Max Bowsher <ma...@ukf.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doyle, Patrick wrote:
> I see that SVN_ASP_DOT_NET_HACK is only enabled for Windows platforms.
> (And, given the use case it is targetted at, that is understandable.)  I
> also see that, as it is implemented now, it allows for only one of two
> possible administrative directory names, ".svn" and "_svn".

I'm fairly certain that we did that deliberately, so that the client
code could prevent all permitted possibilities from being committed into
a repository.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFEEqdbfFNSmcDyxYARAi7nAJ9GrouWAAwmJMNRs8ZM3AlSlgMAbACg2WU3
pEH26AwEqRu6FP8Q91Ztgi4=
=CCSw
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Extending SVN_ASP_DOT_NET_HACK

[Branko Čibej <br...@xbc.nu>]

Doyle, Patrick wrote:
> I see that SVN_ASP_DOT_NET_HACK is only enabled for Windows platforms.
> (And, given the use case it is targetted at, that is understandable.)  I
> also see that, as it is implemented now, it allows for only one of two
> possible administrative directory names, ".svn" and "_svn".  There is a
> comment in the code that the name must point to a statically allocated
> string constant to avoid potential pool lifetime issues.  
>
> I would like to extend this capability to allow for an arbitrary
> administrative directory name specified by an environment variable,
> certainly for my own purposes, but possibly others would find this useful as
> well.
>
> So, I have 2 questions:
> 1) Where can I find out more information about the thought process that went
> into SVN_ASP_DOT_NET_HACK?  I've tried search the issues database, and
> googling it in general, but haven't been able to find anything of substance.
>   
Try the mailing list archives at http://svn.haxx.se/; search for 
ASP.NET. It's a long, twisted, tortuous tale.

> 2) What happens to the pool management if there is a pointer to a string
> stored in the process's environment space?  I suppose, on some processors,
> with some OS's, this may not be distinguishable from malloc()'d memory.  But
> I don't know that for certain.
>   
Pools have a limited lifetime, usually not controlled by the Subversion 
library code. When a pool is destroyed (outside the library), all memory 
allocated from it is freed. If the environment variable table happens to 
refer to that freed memory, you've a good chance of crashing the client.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org