Yes, this is what I currently do. However, it would be nice if I could
prompt for a defect ID if the user didn't put it in, or automatically add a
property when a new file is added to the repository instead of just
rejecting the commit. Rejecting commits makes me feel like I'm being snarky.
-----Original Message-----
From: William Nagel [mailto:bill@stagelogic.com]
Sent: Friday, April 15, 2005 11:07 AM
To: Weintraub, David
Cc: users@subversion.tigris.org; 'Rick Wagner'
Subject: Re: Newbie /etc/subversion question
It would be interesting to allow hook scripts to communicate
bidirectionally with the client, requesting further input when they
need it. That would be a hard feature to get right, though, and it
would require support on both the server and the client.
For now, it should be noted that you can perform a limited amount of
communication back to the user from your hook scripts. Anything that
you write to standard error will be sent back to the client and
displayed. So if you want to require a defect ID, you can parse the
log message to look for one, and if it's not there cancel the commit
with an error message to the user telling them that they need to add a
defect ID to their log message and recommit.
-Bill
On Apr 15, 2005, at 8:51 AM, 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
Received on Fri Apr 15 18:30:29 2005