nice suggestions, but as a workaround you can creatively use the hooks.
for example, you could have the users put the issue number in the log
file, then write a pre-commit hook to verify there is a valid issue
number in it.
-alvin
Weintraub, David wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 16 02:58:53 2005