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

Re: Configuration area in the repository

From: Lele Gaifax <lele_at_nautilus.homeip.net>
Date: 2004-03-31 19:39:49 CEST

>>>>> "John" == John Peacock <jpeacock@rowman.com> writes:

    John> By what you are saying here, you expect the
    John> directory-resident config files to be used _instead of_ any
    John> user homedir config settings. I know that there are people
    John> who would chafe at that restriction.

That's a matter of implementation. I can imagine an hypothetical
/3rd/.subversion/config file containing::

    [miscellany]
    overrides-defaults-in-same-section-of-file = ~/.subversion/config
    use-commit-times = no
    enable-auto-props = no

or something similar.

BTW, in a previous message you talked about keeping the homedir under
version control (as I do :): this fits perfectly with my view, since
by definition from my homedir down I'd expect my ~/.subversion
settings honored, though I'd override it under my "~/work-in-progress"
directory, that may be filled with other-repos working copies, with
their own policies...

    John> You are also introducing some edge cases that I don't think
    John> you have considered. Specifically, a user is able to check
    John> out a "project" at any point in the tree. So for example, I
    John> check out http://.../trunk/docs to work on (pretend I'm a
    John> documentation specialist). However, the site admin placed a
    John> directory-based config file at http://.../trunk that I
    John> should also be getting. As far as the client code is
    John> concerned, my WC root folder is /docs. Do you suggest that
    John> client search all the way up, against the repository, for
    John> possible config settings? How does this work with
    John> disconnected operations?

I see, that's right. But this is not a singularity of this proposal,
since I suppose that in the same situation, the same problem would
occur, even with a repos-centric solution: you surely would like that
in some way, at checkout/update time, your client could query the
server for the equivalent information, maintaining at the same time _a
local cache_. Yes, you can store it in the already existing .svn
metadata dir, but then I guess somebody will ask for an API to manage
that information, since the .svn content is even (and right so!)
read-only...

thanx,
ciao, lele.

-- 
nickname: Lele Gaifax	| Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas	| comincerò ad aver paura di chi mi copia.
email: lele@seldati.it	|		-- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 31 19:40:23 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.