[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bikeshed: configuration override order

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 7 Aug 2010 14:58:54 +0300

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.

> Stefan

[1] That's why we parse ~/.subversion/ *after* /etc/subversion/ and why mailers
can be configured to prompt before honoring the Reply-To header.
Received on 2010-08-07 14:01:16 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.