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.
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
Received on Sat Oct 21 14:36:39 2006