Re: ".svn" directory name no good (in fact, it is worse than I thought)

Out of idle curiosity, since we all seem to be so big on CVS
compatibility and the like, I'm surprised that we never ended up with
SVN as the name of the admin path.

Wouldn't that have solved it? Since it is truly portable across all
filesystems - including one's with braindead extension systems a la 8.3
etc?

Is it too late to revisit that now? Just wondering.

Just keep thinking that this is the kind of thing that would go away if
we didn't do something special.

I do know that on my windows machine, I cannot create via explorer a
.<anything> file. It croaks. Even worseon a network machine.

In order to create a .htaccess file, I have to create a .htaccess.txt
file and then tell apache to use that instead.

However, if the system software happens to do it, or a library call
happens to do it, it usually causes no problems. (I can rename at the
command line).

So perhaps there is something in the system libraries on Windows that is
causing interference when the backwards compatibility to MSDOS is
bypassed and LFNs are used via Windoze only libraries?

Wouldn't something as simple as SVN insteade of a leading dotted path
component handle it all? Or were people up in arms because we could see
the directory and not have unix automagically hide it.

And lastly, why *isn't* the admin path configurable with a .svn default?
How does interoperability have to do with a path component that is
localized to a current filesystem where the library is already
intelligent enough to know where the admin textbase is located via the
configuration file or command line override?

A lot of questions, I know. I'm just thinking out loud. Hope some of
this has been useful. I just feel like standardization was co-opted for
uniformity instead.

I'm going to bed. Hope to see some interesting thoughts in the morning.

Later all.

On Wed, 2003-09-24 at 21:30, james-tigris@jrv.org wrote:

> The admin dir is #defined to '.svn', so in theory, it *could* be
> user-configurable, or just different on win32. But we had this
> discussion years ago, and wanted people to converge on a single
> interoperable standard.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

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