Lele Gaifax wrote:
> John> Your method would require that I add possibly duplicated
> John> .subversion folders to each and every directory in a
> John> potentially very large project.
> Uhm, not exactly: I meant the same, ie, putting the settings for
> example under /trunk would affect everything below that point, no need
> to duplicate it in every subdirectory. This of course means that the
> svn_client layer should walk up the tree to find out the nearest
> settings folder: failing that, it should behave as now, ie reading
> from ~/.subversion/.
You are adding [much] more complexity to the client by doing that. By what you
are saying here, you expect the directory-resident config files to be used
_instead of_ any user homedir config settings. I know that there are people who
would chafe at that restriction. Personally, I would expect the config files
would be additive, with the user ~/.subversion stanzas overriding any other for
a simplistic system. With more sophisticated inheritance code in place, I would
also expect that certain configuration settings could be locked at the
repository level, and others would be overrideable locally.
You are also introducing some edge cases that I don't think you have considered.
Specifically, a user is able to check out a "project" at any point in the
tree. So for example, I check out http://.../trunk/docs to work on (pretend I'm
a documentation specialist). However, the site admin placed a directory-based
config file at http://.../trunk that I should also be getting. As far as the
client code is concerned, my WC root folder is /docs. Do you suggest that
client search all the way up, against the repository, for possible config
settings? How does this work with disconnected operations?
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Lanham, MD 20706
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 31 17:23:10 2004