Re: A proposed solution for svn admin directory names

On Jun 29, 2005, at 8:10 AM, Andrew Thompson wrote:

> Did I miss the discussion about this, or did it not happen?

Since we've discussed this to death in the past, I doubt folks felt
like rehashing over it again. :-)

Here are some notes I have written down from the older discussions:

----------------

   1. Make '.svn' into a runtime option.

       The dirname is '.svn' by default, or something else if you set a
       particular runtime option (either in ~/.subversion/config, or in
       an environment variable.)

       PROS:

         - ASP.NET users have a convenient workaround for IIS: just
           set the runtime option to '_svn' or whatever they want.

       CONS:

         - ASP.NET working copies become non-portable (unless Unix
           clients temporarily set the runtime option to the same
thing.)

         - large amount of coding work. (converting dirname from a
           compile-time variable to a run-time one.)

   2. Publish/advertise a one-line patch.

       The patch just changes the single '#define .svn' line.

       PROS:

         - ASP.NET users have a workaround for IIS: recompile with the
           patch, or use a 'special' win32 client binary.

         - no coding needed.

       CONS:

         - Every win32 client (svn, tortoisesvn, svnup, etc.),
           must now publish 'special' ASP.NET binaries along side the
           'normal' binaries.

         - ASP.NET working copies become non-portable.

    3. "Be strict in what we create, tolerant in what we read."

        On win32, create "_svn" (or something similarly visible). On
        all other systems, create ".svn". When reading a working copy,
        look for both.

        PROS:

         - ASP.NET users require no workarounds at all, and happily
           interoperate with Unix.

         - easy to code.

        CONS:

         - libsvn_wc will do *two* disk stats to figure out if a
           directory is under version control. (but only if it's a
           Unix client looking at a Win32 working copy, or vice versa.)

    4. Go back to using 'SVNADM/' or similar.

        PROS:

         - works everywhere, full interoperability.

         - a one line code change.

        CONS:

         - no more hidden dirs on Unix. (My sense is that *most* --
           but not all -- unix users still prefer hidden directories.)
------------------

So what's being proposed is #1 again. What's interesting is that the
con of 'large amount of coding work' may not be true anymore, if it's
really possible to call getenv() from a macro.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 15:21:56 2005