On Nov 16, 2005, at 17:52, Matt England wrote:
>>> If you want to prevent anyone from committing, for example, *.o
>>> to the repository, you can write a pre-commit hook that gets a list
>>> of all files in the transaction, does pattern matching on them to
>>> if any prohibited files are listed, and if so, outputs a message to
>>> that effect and exits with a nonzero code, which cancels the commit.
>>> The user then corrects the problem and attempts the commit again.
>> I suppose this is the only server-side "master" control to do what
>> I seek?
> If it is, I'm wondering how the default global-ignores value is
> Is it:
> 1) hard-coded into the source code
> 2) in some server-system-wide config file
> 3) something else?
> If #2, then where is this config file? I want to change it to
> include some more files.
> If it's in #1, then I may be interested in changing said source file
> (s) and rebuilding the server software to change the default global-
> ingores value so that I don't have to hack away at a pre-commit
> repo hook for every repository.
As far as I know, files are ignored exclusively on the client side.
The server accepts anything you throw at it. The default global
ignores would probably be hard-coded into the Subversion client
library code. So while you could change that, you would need to force
your users to use the client you compile. If they decide they want to
use the latest release of TortoiseSVN instead, they'll bypass your
changed global ignores.
I think the only way to prevent someone from committing something is
to write a pre-commit hook that defines the rules.
Now, thinking about this problem, it doesn't seem too far-fetched to
me to imagine a pre-commit hook that can read a Subversion client
configuration file and apply its rules to the incoming transaction—
that is, check that the transaction conforms to the configuration and
send an error otherwise—in effect letting you define a config file,
provide it to all your clients, and then put it on the server for the
hook to read and enforce. Looking through the config file, it looks
like the only settings such a script would have to look at are the
global-ignores and enable-auto-props settings in the [miscellany]
group, and if enable-auto-props is true, then the list of automatic
properties defined in the [auto-props] group. Seems like this might
not be too difficult to write. Maybe someone has even done so already.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 16 18:46:04 2005