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

Re: 'SVN' to '.svn'

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-05 01:02:53 CEST

On Tue, Sep 04, 2001 at 05:28:57PM -0400, Greg Hudson wrote:
>...
> > The wc library could recognize several alternatives, like RCS, which
> > looks for version files in "RCS/", ".rcs/" and "./".
>
> I have no strong objection to having a short, fixed list of
> alternatives, although I think it's going overboard.

This whole thread is going overboard.

*ALL* of the problems stated in this thread, and their potential solutions,
have been caused by the (ahem) "useful" functionality of a variably-named
administrative directory.

Come on, people. *WHY* WHY WHY?

Flexibility for flexibility's sake is a bogus goal. It needs to be useful.
Programs assert particular behavior all the time, we don't have to cater to
every possible desire.

Fix the darn directory as '.svn' and be done with it.

Stop and think about it: *why* must it be changeable? Provide a good
argument.

And when you starting coming up with that argument, ask whether CVS lets you
change its admin dir name, or .cvsignore. Do people complain? I've never
heard a single bad word about that. And does your argument vacuously state
that people want that flexibility? Then where is the support for that
assertion? "But it should be visible" Ok, to what? ls? It is, if you pass
-a. To programs such as vc-mode? They can see .svn just as easily as SVN.

So far, I've heard a ton of support of '.svn', an semi-support from GregH
for it, and one voice for "flexibility" (which sent us down this mess).

-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006

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.