[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' WAS: RE: Successful bootstrap on Mac OS X

From: B. W. Fitzpatrick <fitz_at_red-bean.com>
Date: 2001-09-04 17:15:32 CEST

> cmpilato@collab.net writes:
>
> > I've been casually nudging (off-list) for `.svn' for about 6 months
> > now. You'd have NO problem getting my +1 on this one.
>
> The problem here is not the idea of using ".svn" or ".SVN", but rather
> to the idea of *forcing* this to be the only choice.
>
> Really, a lot of people *like* having visible administrative
> directories; it's not just a lazy holdover from CVS. For example, I
> know that Karl and I *want* to enter a directory and instantly be
> reminded that it's under revision control. We don't want to have to
> remember to 'ls -l' to find out.
>
> Still, we understand the other use case -- hiding the directory is
> especially useful on case-insensitive systems.
>
> We've had this discussion before, and I believe the consensus was that
> the name of the administrative directory would be a run-time switch
> read out of a user's .svnrc. The .svnrc would give 2 or 3 choices:
> "SVN", ".SVN", ".svn", or something like that.

Well, I'm +1 on .svn since I keep everything under version control and
I don't care if I see the dir or not. I mean, if you really want a
reminder that you're in a version controlled directory, then modify
your PROMPT to let you know. :)

I really like the "choices" concept of the above and I would really like
to implement an entirely different choice (but I unfortunately don't
have the time right now): The option to keep the SVN/.SVN/.svn turds
outside of the working copy entirely (or in the root directory of the
working copy). I know that having the administrative directories in
each directory is a big win for a lot of people (of course there are
hundreds of advantages to this), but for others, it's a huge
shortcoming.

Anyway, I just wanted to get this out and into the list
archives. Maybe I (or someone) will be able to get to this post 1.0.

-Fitz

 
> So, (Branko), if config-file-parsing is working, perhaps somebody can
> modify client/cmdline/main.c to start parsing an .svnrc file. Then in
> svn_wc.h, we can define SVN_WC_ADM_DIR_NAME at runtime.
>
> Of course, there's a "wrench" in this idea. Look at Karl's comment in
> svn_wc.h:
>
> /*** Administrative subdir. ***/
>
> /* Ideally, this would be completely private to wc internals (in fact,
> it used to be that adm_files.c:adm_subdir() was the only function
> who knew the adm subdir's name). However, import wants to protect
> against importing administrative subdirs, so now the name is a
> matter of public record.
>
> ### kff:
> Note that the import issue throws a wrench in our tentative plans
> to give client users optional control over the adm subdir name.
> Sure, I can tell my client to override this constant, but all the
> other people in the world importing trees don't know about my
> choice. What happens when I try to check out their tree? Perhaps
> a centralized decision is called for after all. */
>
> #define SVN_WC_ADM_DIR_NAME "SVN"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.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:39 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.