RE: Bikeshed: configuration override order

> > 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.
>
>
 
> 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

This is why I am trying to say it needs to be a two layer configuration. The settings on the server are enforced before anything is committed to the repo. The settings are also sent to the client (in some way) yes, to avoid that 5 minute or whatever wait. However I think shooting for client enforcement and trusting the client isn't something svn should rely on.

It is similar to writing a web app where you have client side validation/sanitation... but you still ALWAYS duplicate that validation/sanitation on the server... because you really have no way to trust that someone isn't posting bad data to your server/services using a client that isn't the one you provided.

I think the same approach has to be taken here. The server side config is provided to the client as a convenience but it is always enforced on the server (without the need to write scripts) because you can't always trust the client to be using or respecting "forced" repository configuration.

BOb
 
Received on 2010-08-10 19:26:25 CEST