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 01:15:04 2005