This brings up another problem with Subversion: The Admin has little power
to enforce CM standards. I am basically given a single big stick: I can
prevent someone from committing a change I don't want. But, there is little
else I am allowed to do.
For example, if someone does a commit, I'd like to prompt them for a defect
ID. Yes, I know that the TortoiseSVN client can do this, but what if I want
to make sure it is enforced on the server side, and not depend upon a
particular Subversion client? What if a developer creates a new file, and
doesn't set the property svn:keyword = "Id" on it? Or, if a file is text,
make sure it contains a copyright string inside of it?
Some of this could be done with an expanded svnadmin command that would
allow an administrator to do all of the things that svn can do without first
creating a working directory. Others would require some way for the server
to examine the version of the file that is sitting on the client's machine
without that version of the file being added to the source archive.
I like the fact that Subversion's hooks run on the server machine and not
the client's machine. In ClearCase, I had something similar called
"triggers", but they ran on the client's machine. The trigger scripting
language had to be installed on the client's machine. Plus, the triggers had
to be written in such a way that they would work with various versions of
the scripting language on the wide variety of client systems out there. The
advantage of course, is that it allowed me to examine the modified file on
the client's machine before being placed into the source archive.
-----Original Message-----
From: Rick Wagner [mailto:wagnerric@condor.cxo.cpqcorp.net]
Sent: Thursday, April 14, 2005 7:13 PM
To: users@subversion.tigris.org
Subject: Re: Newbie /etc/subversion question
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 15:53:04 2005