> 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
Received on 2010-08-10 18:12:49 CEST