Not having a SVN wide set of configuration information is going to be a
problem. Relying upon the local .subversion directory is not a good idea
for stuff that we have to rigidly control.
I like the suggestions put forth in the response. There needs to be a way
to have subversion wide control of things, such that local changes are
ignored.
MB
--
Mike Brown (Michael.L.Brown@Philips.com)
Lotus Bloats: Michael L Brown/MSN/MS/PHILIPS
Philips/ADAC, Madison, WI
Desk: 608-288-6969 Fax: 608-298-2101
PMS direct: 164-6969
You design it, I'll build it!
Rick Wagner <wagnerric@condor.cxo.cpqcorp.net>
04/14/2005 06:13 PM
To: users@subversion.tigris.org
cc: (bcc: Michael L Brown/MSN/MS/PHILIPS)
Subject: Re: Newbie /etc/subversion question
Classification:
On Thursday 14 April 2005 2:35 pm, Weintraub, David wrote:
> You should understand that the /etc/subversion directory only applies to
> the client machines and not the machine that is running the Subversion
> server where the archive itself is stored. A user can override the
settings
> of /etc/subversion by creating their own configuration file under their
> $HOME directory. Unless you have all of your users telnetting into the
same
> Unix box in order to run Subversion, setting up /etc/subversion really
> doesn't make too much sense.
>
> There are two client configuration files in Subversion. There's the
> /etc/subversion, and there's the configuration files under each user's
> $HOME/.subversion directory.It is $HOME/.subversion and not the
> /etc/subversion directory that is created when a user executes
Subversion
> for the first time (including just typing "svn -version"). The
> documentation is a bit confusing on this issue.
>
> I've never bothered with /etc/subversion because it didn't make sense to
> use it. If I am automouting $HOME directories, it makes more sense to
put
> the default files under /etc/skel and have them copied to
$HOME/.subversion
> when I create the user's ID anyway. Otherwise, I have to copy the
> /etc/subversion directory to all the various clients.
This brings me to wonder about a new feature: server side client
configuration. There you would put something like /etc/subversion on the
server side, say in the .../conf/ directory. The API would have to be
extended to allow the client to request the config info. Clients would
have
to be modified to request it, but I suspect there is a 'readConfig' call
in
the standard library that already aggregates config info from /etc/ then
$HOME. This would ease distribution of standard configurations, and
propagation of changes, for repository wide policies.
Possibly there could be '-pre' and '-post' files. The '-pre'
configuration
would be fetched, then the local configs (/etc/subversion, then
~/.subversion
as now) applied, then the '-post' applied. Thus '-post' would enforce
options you don't want overridden. The alternative to '-pre' and '-post'
would be something like an 'immutable' keyword in the master config.
Enforce is probably a strong characterization; it all depends upon
trusting
the clients to obey the rules. Of course an adventuresome sole could
modify
the client sources to make them disobey the rules. But then thats way
most
system administrators are armed with big sticks ;) .
--rick
> -----Original Message-----
> From: Michael L Brown [mailto:michael.l.brown@philips.com]
> Sent: Thursday, April 14, 2005 1:54 PM
> To: users@subversion.tigris.org
> Subject: Newbie /etc/subversion question
>
>
>
> Due to a timeframe constraint, I can't go digging into every posting in
the
> archive.
>
> I did find a little bit to help that kinda got me going, but I still
have a
> couple of questions.
>
> Reference: Advanced Topics - Runtime Configuration Area
>
> The book says that the system wide configuation area is /etc/subversion.
> That directory was not created when the package was installed (Solaris
8),
> so I created it manually.
>
> Reference: Advanced Topics - Configuration Area Layout - third paragraph
>
> The book says that to get a default set of configuration settings, is to
> remove your copy and run a command, like "svn --version", and it will
> recreate the directory and populate it with default info.
>
> My questions. The /etc/subversion directory can't be created because
svn
> doesn't have permission to create said directory. After manually
creating
> the directory, and running the svn command again, it didn't populate it
> with default files. How can one get it to do that? Why wasn't
> /etc/subversion created when it was installed?
>
> Thanks for any pointers.
>
> MB
> --
> Mike Brown (Michael.L.Brown@Philips.com)
> Lotus Bloats: Michael L Brown/MSN/MS/PHILIPS
> Philips/ADAC, Madison, WI
> Desk: 608-288-6969 Fax: 608-298-2101
> PMS direct: 164-6969
> You design it, I'll build it!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 15 17:13:03 2005