On Tue, 2010-08-10, C. Michael Pilato wrote:
On 08/10/2010 01:25 PM, Julian Foad wrote:
Oh? All I know about Andrew's particular requirements related to this
query is what's quoted above - If I ... accidentally leave the banned
buildlog.htm file in ... - which sounded vaguely like a
-Original Message-
From: Julian Foad [mailto:julian.f...@wandisco.com]
Sent: Tuesday, August 10, 2010 6:25 PM
To: C. Michael Pilato
Cc: Bolstridge, Andrew; Subversion Development
Subject: Re: Bikeshed: configuration override order
[snip]
Oh? All I know about Andrew's
On 11.08.2010 11:05, Bolstridge, Andrew wrote:
The second aspect: client-stored passwords, this isn't so much about storing
them on the client but about having different ones. Enterprises want
single-signon, ie, a single password, centrally held, that is used for all
apps. They don't really
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
On 08/10/2010 12:15 PM, Julian Foad wrote:
On Tue, 2010-08-10 at 17:12 +0100, Bolstridge, Andrew wrote:
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
On 08/10/2010 01:10 PM, C. Michael Pilato wrote:
On 08/10/2010 12:15 PM, Julian Foad wrote:
On Tue, 2010-08-10 at 17:12 +0100, Bolstridge, Andrew wrote:
Summary...
There are two issues here...
1. The repo admin wants to enforce what is commited to their repo.
This
exists with scripts but
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
On 08/10/2010 01:25 PM, Julian Foad wrote:
Oh? All I know about Andrew's particular requirements related to this
query is what's quoted above - If I ... accidentally leave the banned
buildlog.htm file in ... - which sounded vaguely like a requirement for
a path-based rule. Maybe I missed
On Tue, Aug 10, 2010 at 06:25:15PM +0100, Julian Foad wrote:
All I know about Andrew's particular requirements related to this
query is what's quoted above - If I ... accidentally leave the banned
buildlog.htm file in ... - which sounded vaguely like a requirement for
a path-based rule. Maybe
On 08/07/2010 12:18 PM, Greg Hudson wrote:
My thinking about repository configuration is that the uses cases should
be divided into two categories:
1. Stuff that isn't really client configuration at all, like
auto-props, should come from the repository instead, and should only
come from
On 08/07/2010 12:18 PM, Greg Hudson wrote:
My thinking about repository configuration is that the uses cases
should be divided into two categories:
1. Stuff that isn't really client configuration at all, like
auto-props, should come from the repository instead, and should
only
come
On Tue, 2010-08-10 at 14:24 -0400, C. Michael Pilato wrote:
The foremost bit of client configuration that CollabNet's Subversion
customers are demanding (besides auto-props, which I think we all agree on)
is a way for the server to set a policy which dictates that clients may not
use plaintext
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
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.
So. We could have an allow-repos-config switch (parallel to
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
On Sat, 2010-08-07 at 07:58 -0400, Daniel Shahaf wrote:
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
* Client site-wide configuration (/etc/subversion)
* Client user-specific configuration (~/subversion, 'svn --config-
dir')
* Repository-dictated configuration (as described above)
* Explicit configuration supplied by the client application
('svn --config-option', or Eclipse
On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson ghud...@mit.edu wrote:
On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
I'm doing some more thinking about repository-dictated configuration,
I get nervous when I see people talk about repository-dictated
configuration as an extension of
On 06.08.2010 19:50, Hyrum K. Wright wrote:
I'm doing some more thinking about repository-dictated configuration,
and one of the things I'd like some discussion on is the order of
configuration overrides. The consensus is that the repository can not
be sure that it's dictated configuration is
On Fri, Aug 6, 2010 at 1:08 PM, C. Michael Pilato cmpil...@collab.net wrote:
On 08/06/2010 01:50 PM, Hyrum K. Wright wrote:
I'm doing some more thinking about repository-dictated configuration,
and one of the things I'd like some discussion on is the order of
configuration overrides. The
On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson ghud...@mit.edu
wrote:
On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
I'm doing some more thinking about repository-dictated
configuration,
I get nervous when I see people talk about repository-dictated
configuration as an
On Fri, Aug 06, 2010 at 02:28:11PM -0400, Bob Archer wrote:
But really why do people want this. I think it is so some settings like
auto-props and other things that need to be set for a specific project will
take place without having to distribute a config or send an email with make
sure
22 matches
Mail list logo
