>>>>> "John" == John Peacock <jpeacock@rowman.com> writes:
John> 1) Initialization - is the global config used when creating
>> 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> Then you can take away the discussion that your proposal was
John> not clear (to me at least ;) as to what you were actually
John> proposing.
Sorry, but English is not my native tongue. As said, I was chatting
with Ben when I submitted the issue, and it was (apparently) clear to
him.
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> You still have to deal with the possibility of the same
John> settings in both locations and how they interact. In my
John> mind, this is a far more important part of the design
John> discussion than the actual location of the additional config
John> stanzas.
John> There is also the issue of Namespace collision in the
John> repository. If I decide to place my entire home directory
John> under version control (not unheard of), your proposed
John> './.subversion' will collide with the existing
John> '~/.subversion' directory. This is not a killer problem,
John> but the code would have to deal with the fact that in this
John> case the local /directory/ config and the local /user/
John> config are one and the same.
Well, I think that the very same problem will raise, any how you
decide to tackle the issue. I mean, in every way there will be a
chance that the repos-wide settings collide with the user-owned ones
in its ~/.subversion/, doesn't it?
John> Additionally, there are existing issues with Win32
John> development (specifically Visual Studio Web projects) when a
John> directory or file starts with a period (only an extension
John> and no filename). Given that it is already a problem to
John> have .svn, it would not be good to then go ahead and add yet
John> another problem case. The Win32 people are very sensitive
John> to perceived slights of their worldwide dominance. ;~0
That is another story: the solution to the '.svn' dilemma on win32 can
be applied to the '.subversion' folder. When there will be the
possibility of keeping wc metadata out of the working dir, by any
change there will be a mechanism to store "per-directory" information
somewhere else in place. The very same mechanism could then be used
to store "that-directory-auto-props-settings", for example.
John> I'm not even sure where you intend the './.subversion' file
John> to be located. No, *each* subdirectory of a repository
>> may contain the .subversion
John> ^^^^^^^^^^ You mean Working
John> Copy here, right?
Yes, of course.
>> settings folder, that applies on the containing directory and
>> its subtree. This way you can get different policies in
>> different part of the repository.
John> ^^^^^^^^^^ Again, you are proposing a WC-centric
John> configuration file, that just may be stored in the
John> repository sometimes.
Yes, sorry for the confusion. To make it clear, my proposal touches
*only* the client-side of the matter.
John> I have to say that I would not find this (directory centric
John> configs) as useful as, for example, a property associated
John> with a containing directory. In both cases, to do it right
John> would involve the tough discussion of inheritance and
John> collision. I would rather set the project-centric
John> configuration once at the top level of the project (as a
John> property), and have that inherited by the entire project.
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/.
The admin will the be free to impose or not particular settings in
different areas of the repository, and the single developers too, to
some degree. As said, I keep under SVN several third-party software
(think at Plone and all the related material, that come from various
SF.net CVS repositories). I'd like to be able to say "under /3rd do
not *ever* apply svn keywords, keep the upstream CVS ones, but do
activate them all under /trunk, that host my own applications and
customizations". With a repository-centric approach, this would be
impossible, as it is now.
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 16:51:01 2004