[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 16:50:28 CEST

>>>>> "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

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