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

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

From: B. W. Fitzpatrick <fitz_at_red-bean.com>
Date: 2003-09-25 06:24:16 CEST

Files <files@poetryunlimited.com> writes:
> 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.

At what point do we stop revisiting things?
 
> 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.

A workaround... and from what I can tell, there's currently a workaround
for this problem on Windows, no?
 
> 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.

I dunno. This bugs me a) because I'm tired of rehashing this and b) why
do *we* have to compensate for some other vendor's broken-ass software?
 
> 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?

We've been through all of this a *million* times in the last 3.5
years--the name of the admin directory, why we don't want it
configurable by a directive... the list goes on... and quite frankly,
I'm just tired of arguing about it.

We discuss and discuss and discuss and make a decision and a year later,
folks show up with a million reasons (I'm not going to argue about the
validity of these reasons) why we should have zigged when we zagged.
I'll betcha five bucks that if we change it to SVN, a year from now
*someone* will have 50 reasons (just as valid) why we should change it
*back* to .svn. *thud*

This isn't directed at you, Shamim--this is just one of the hazards of
doing Open Source development. *sigh*

-Fitz

--
Brian W. Fitzpatrick    <fitz_at_red-bean.com>   http://www.red-bean.com/fitz/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 25 06:26:00 2003

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.