> Summary... > > There are two issues here... > > 1. The repo admin wants to enforce what is commited to their repo. This > exists with scripts but common request can be made inherient repo settings > (probably need to be path based). >
The issue with pre-commit hooks is that they are run after all data is transferred - so if I commit loads of data, and accidentally leave the banned buildlog.htm file in... I'll find out about it after half an hour's commit.. and have to repeat the process. It's not that major an issue but repo-set config would fix it. Auto-props is a more tricky problem that would just be nicely solved by telling the clients what settings to use. > 2. The admins want to simplify config for clients committing to repos that > have various enforcements made (see item 1) without needing to deal with > distirbuting client config files or what have you. This is the biggie - one remote worker decided he didn't have to read all the email I sent him on how to set up svn, and ended up committing 2 Gb of crud to my lovely repository. We have a pre-commit hook for all file extensions now. Perhaps the ideal (and easiest) way to resolve all this is to have the repo inform the client of mandatory settings that it expects to be set, and perhaps optional ones, and either automatically download a new set of configs to the client, or have the client fail until its config is in compliance with the repo's configuration settings. A new option could be added to the client to download and use the config from the repo. This could be made automatic, every time the client runs a repo-contacting command, it gets a hash or guid from the server that describes the config, and if that doesn't match what the client has, the client can run the config-download in the background (and then re-try the command it was trying to do). Perhaps allow the client to store multiple config files and use the one that matches the repo, along with the default one that we currently have. The server config can then only set the bits it wants, missing config options are used from the default. There's scope in there for the client to download the repo's chosen settings, and then override them anyway. There's scope for the repo to mandate a few options, giving the client a choice of going to play elsewhere or accept the restrictions. Anyway, that's my thoughts on the subject. Repo-driven config, even if its just an easy way to download a new set to the client instead of the email 'use this file, or use this registry script' is a huge step forward. Andy