>>>>> "John" == John Peacock <jpeacock@rowman.com> writes:
John> Lele Gaifax wrote:
>> I opened an enhancement issue on the subject, see
>> http://subversion.tigris.org/issues/show_bug.cgi?id=1813
John> The generally accepted practice on this project is to not
John> create issues without discussing the subject on the dev list
John> first (this is different than lots of projects). In this
John> case, the need for repository-wide configuration files is
John> well known, and impacts a number of existing proposed
John> features, see #890 in addition to 1002 (which you mention).
John> There are others, I am sure.
John, I do know the matter, and I even chatted with Ben and others
before issueing it. Ben said that at one point he will create a
meta-issue to collect these ideas.
John> In specific, your proposed solution is not that helpful
John> because you don't deal with several issues inherent in the
John> topic:
John> 1) Initialization - is the global config used when creating
John> the user's local configuration? This is one facet of
John> Subversion which others have noted is very annoying to have
John> hardcoded in the binary instead of configurable. This kind
John> of repository-defaults should probably be stored in conf/
John> somewhere.
Uh? My proposal simply add a new place to look for settings, that is
look also in './.subversion' after '~/.subversion'. The suggested
approach has several advantages over a per-repository new conf/
setting.
John> 2) Collision - are repository-wide settings additive with
John> user config, or do the globals trump the user settings (or
John> more likely vice versa).
The proposal is an /alternative/ to having such repos-wide settings.
John> 3) Updates - if the repository-wide settings are updated,
John> how is that communicated to the client?
In fact, this is why I think my idea is much simpler and as effective
as the repos-wide one, without requiring additional code to transfer
to/from the server another config file.
John> 4) Mixed WC's - if you are proposing storing
John> repository-specific defaults, how to you handle working
John> copies with svn:external links to other repositories. There
John> are inheritance issues here, too.
No, each directory could contain its own .subversion folder, and the
developers are free to put it under revision control or not.
John> I'm not even sure where you intend the './.subversion' file
John> to be located. That is a relative path, but you don't say
John> where it is relative to; I'm assuming you are talking about
John> the repository root (i.e. in the repository itself). If so,
John> there is no point in using the special ".subversion"
John> filename, since that is an artifact of *nix filesystem
John> semantics (hidden file) which has no [current] special
John> handling within the Subversion filesystem code.
No, *each* subdirectory of a repository may contain the .subversion
settings folder, that applies on the containing directory and its
subtree. This way you can get different policies in different part of
the repository. For example, mine have a '/3rd/' tree that contains
external software synced tipically with some sourceforge.net CVS
repository: for obvious reasons, I do not want SVN properties be
active there and below, while it would be nice if in the other trees
(say, '/mine/trunk') I could activate auto-props.
John> I'm not trying to dissuade you from making suggestions, just
John> pointing out that the issue has been considered before, and
John> it is much more complex than might be initially obvious.
Ya, of course. That's the main reasoning behind making an issue out
of it.
thanx,
bye, 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 15:58:53 2004