RE: Bikeshed: configuration override order

> Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200:
> > On 07.08.2010 12:44, Daniel Shahaf wrote:
> >> If corporations want to have configuration override, fine.
> >>
> >> But I want a way to disable that completely. I don't
> necessarily want to
> >> allow a random sourceforge repository to control my auto-props
> settings for
> >> a wc of that repository.
> >
> > Maybe a stupid question: why not?
>
> Why don't I let ezmlm configure my mailer's "use html?" setting?
>
> If I run with use-server-config=ask, I might accept the prompt most
> of the
> time. But, ultimately, it's software I run on my computer, and I
> should
> have the final say over what configuration it runs with.[1]
>
> I suggest the following:
>
> * one can say "don't honor the server's suggestions" without
> recompiling the client
>
> * one cannot make the client dishonor the suggestions *while
> reporting that
> it shall honor them* without recompiling.
>
> This way the server can rely on the self-report (and could even
> refuse the
> checkout if the self-report says "I will dishonor").
>
> > I mean, if the developers of that project agree on certain rules
> and
> > decide to enforce them, shouldn't you also follow those rules if
> you use
>
> I agree with stsp's point elsethread: if it's truly project
> configuration,
> it doesn't belong in ~/.subversion/.
>
> > that repository/wc? Especially if you have commit access there,
> it would
> > be very bad if you would commit something that would break those
> rules.
> >
>
> No, it won't be "very bad". It will mean I have to make another
> commit to
> fix the broken auto-props.
>

A repository administrator already has a way to enforce stuff like this via pre-commit hooks. Isn't that satisfactory. Wouldn't having repository/service specified settings just make it easier for devs so they don't have to worry about stuff like this to match every repository they deal with?

Perhaps make enforcing certain auto-props and other possible client settings that affect what is more of a config thing rather than needing to write hook scripts is enough.

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

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.

If these remain separate there is not way a client could over ride the repo admins whishes even if they did build there own client exe that overrode any repo config since it would be enforced via item 1.

BOb
Received on 2010-08-09 23:11:53 CEST