> -Original Message-
> From: Bob Archer [mailto:bob.arc...@amsi.com]
> Sent: woensdag 11 augustus 2010 15:42
> To: Branko Čibej; dev@subversion.apache.org
> Subject: RE: Bikeshed: configuration override order
>
> > On 11.08.2010 11:05, Bolstridge, Andrew wrote:
> 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 re
On Wed, Aug 11, 2010 at 6:05 AM, Bolstridge, Andrew
wrote:
>> -Original Message-
>> From: Branko Čibej [mailto:br...@xbc.nu]
>> Sent: Wednesday, August 11, 2010 10:37 AM
>> To: dev@subversion.apache.org
>> Subject: Re: Bikeshed: configuration override o
> -Original Message-
> From: Branko Čibej [mailto:br...@xbc.nu]
> Sent: Wednesday, August 11, 2010 10:37 AM
> To: dev@subversion.apache.org
> Subject: Re: Bikeshed: configuration override order
>
> On 11.08.2010 11:05, Bolstridge, Andrew wrote:
> > The s
On Tue, Aug 10, 2010 at 11:12:25PM +0200, Branko Čibej wrote:
> The issue isn't storing passwords, but storing them insecurely, i.e., in
> plaintext on disk. Which is what Subversion does by default unless it
Not "by default" anymore. As of 1.6.0, the default is to *ask*
the user whether storing p
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 rea
> -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?
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
C. Michael Pilato wrote on Tue, Aug 10, 2010 at 14:24:30 -0400:
> 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 pl
On 10.08.2010 20:57, Greg Hudson wrote:
> 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 polic
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 plaint
> 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
>
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 f
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.
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 misse
> > 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
On Tue, 2010-08-10, C. Michael Pilato wrote:
> 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 adm
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
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 inh
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
> settings
> > (probably need to
> 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 aft
> 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
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 necessari
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
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 que
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 th
Stefan Sperling wrote on Fri, Aug 06, 2010 at 21:51:37 +0200:
> Why do we have settings in the individual client config that all users
> would want to share anyway?
>
> So maybe having auto-props in the config is part of the problem? What about
> having an svn:auto-props property at the parent dir
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
> sur
> On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson
> 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
On 06.08.2010 20:18, Hyrum K. Wright wrote:
> On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson 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 ab
On 06.08.2010 20:13, Greg Hudson 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 the general c
On Fri, Aug 6, 2010 at 1:08 PM, C. Michael Pilato 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 consensus is that
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 re
[Hyrum K. Wright]
> We currently have several (implemented or proposed) sources for
> configuration information, and I think they should be searched in the
> following order:
Ah, and what about things like global-ignores or auto-props, where you
can set multiple "properties" per option?
If the r
On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson 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 the general
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 the general configuration framework.
There are a lot of things a reposi
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 consensus is that the repository can not
> be sure that it's dictated configurat
> * 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 conf
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 received and respected by
the client, so it shou
39 matches
Mail list logo
