On Wed, Oct 3, 2012 at 2:51 PM, Paul Burba wrote:
> On Wed, Oct 3, 2012 at 2:38 PM, C. Michael Pilato wrote:
>> On 09/12/2012 03:31 PM, Paul Burba wrote:
>>> Hi All,
>>>
>>> A while back I started working on a branch[1] to implement inheritable
>>> properties, ultimately in pursuit of a server di
On Wed, Oct 3, 2012 at 2:38 PM, C. Michael Pilato wrote:
> On 09/12/2012 03:31 PM, Paul Burba wrote:
>> Hi All,
>>
>> A while back I started working on a branch[1] to implement inheritable
>> properties, ultimately in pursuit of a server dictated config
>> solution, as discussed here
>> http://svn
On 09/12/2012 03:31 PM, Paul Burba wrote:
> Hi All,
>
> A while back I started working on a branch[1] to implement inheritable
> properties, ultimately in pursuit of a server dictated config
> solution, as discussed here
> http://svn.haxx.se/dev/archive-2012-02/0207.shtml
>
> I've finished the ge
On Fri, Sep 14, 2012 at 2:28 PM, Julian Foad wrote:
> Hi Paul.
>
> In short, I think I'm convinced by your argument. Thanks!
Julian, you make me nervous when you r answers are this short :-)
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Hi Paul.
In short, I think I'm convinced by your argument. Thanks!
- Julian
Paul Burba wrote:
> On Thu, Sep 13, 2012 at 2:59 PM, Julian Foad wrote:
>> I'm seeing something in the above diagram that may be troubling. It
>> says that, in a mixed-rev WC, if I have no local mods, nevertheless
On Thu, Sep 13, 2012 at 2:59 PM, Julian Foad wrote:
> Paul Burba wrote:
>> On Thu, Sep 13, 2012 at 10:47 AM, Julian Foad wrote:
>>> parent dir in repo NODE
>>> | | \_
>>> | v v
>>> +-wc root dirBASEACTUAL
Subversion Development'
>
> Sent: Thursday, 13 September 2012, 18:27
> Subject: Re: [RFC] Inheritable Properties Branch -- caching props in WC DB
>
> Bert Huijben wrote:
>
>>> From: Julian Foad [mailto:julianf...@btopenworld.com]
>>>
>>> This bra
Bert Huijben wrote:
>> From: Julian Foad [mailto:julianf...@btopenworld.com]
>>
>> This branch caches properties of certain repository nodes, in a new place
>> in the WC DB.
>>
>> I haven't examined it at all yet. The Wiki page says: "The cache will be
>> stored in a new BLOB column in the
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: donderdag 13 september 2012 22:18
> To: Paul Burba
> Cc: Subversion Development
> Subject: Re: [RFC] Inheritable Properties Branch -- caching props in WC DB
>
> Paul Burba
Paul Burba wrote:
> [1] https://svn.apache.org/repos/asf/subversion/branches/inheritable-props
This branch caches properties of certain repository nodes, in a new place in
the WC DB.
I haven't examined it at all yet. The Wiki page says: "The cache will be
stored in a new BLOB column in the NO
Paul Burba wrote:
> On Thu, Sep 13, 2012 at 10:47 AM, Julian Foad wrote:
>> parent dir in repo NODE
>> | | \_
>> | v v
>> +-wc root dir BASE ACTUAL
>> | | |
>> |
Oh, be forewarned, if you build the branch and use it, you will likely
auto-upgrade your WC. See
http://svn.haxx.se/dev/archive-2012-08/0327.shtml
On Wed, Sep 12, 2012 at 3:31 PM, Paul Burba wrote:
> Hi All,
>
> A while back I started working on a branch[1] to implement inheritable
> properties,
On Thu, Sep 13, 2012 at 10:52 AM, Julian Foad
wrote:
> Paul Burba wrote:
> [...]
>> [1] https://svn.apache.org/repos/asf/subversion/branches/inheritable-props
>
>
> I had to apply the following patch to avoid a circular dependency, to get the
> branch to link on my (Ubuntu GNU/Linux) system:
>
>
On Thu, Sep 13, 2012 at 10:47 AM, Julian Foad
wrote:
> Paul Burba wrote:
>
>> A while back I started working on a branch[1] to implement inheritable
>> properties, ultimately in pursuit of a server dictated config
>> solution, as discussed here
>> http://svn.haxx.se/dev/archive-2012-02/0207.shtml
Paul Burba wrote:
[...]
> [1] https://svn.apache.org/repos/asf/subversion/branches/inheritable-props
I had to apply the following patch to avoid a circular dependency, to get the
branch to link on my (Ubuntu GNU/Linux) system:
[[[
Index: subversion/libsvn_ra_svn/client.c
==
Paul Burba wrote:
> A while back I started working on a branch[1] to implement inheritable
> properties, ultimately in pursuit of a server dictated config
> solution, as discussed here
> http://svn.haxx.se/dev/archive-2012-02/0207.shtml
>
> I've finished the generic inherited properties solution
On Mon, Feb 27, 2012 at 6:33 PM, Branko Čibej wrote:
> On 28.02.2012 00:20, Paul Burba wrote:
>> On Thu, Feb 16, 2012 at 12:31 PM, Branko Čibej wrote:
>>> On 16.02.2012 16:46, C. Michael Pilato wrote:
On 02/16/2012 05:50 AM, Branko Čibej wrote:
> On 15.02.2012 21:18, Greg Stein wrote:
>>
On 28.02.2012 00:20, Paul Burba wrote:
> On Thu, Feb 16, 2012 at 12:31 PM, Branko Čibej wrote:
>> On 16.02.2012 16:46, C. Michael Pilato wrote:
>>> On 02/16/2012 05:50 AM, Branko Čibej wrote:
On 15.02.2012 21:18, Greg Stein wrote:
> And thinking on that: how does the client do inheritance
On Thu, Feb 16, 2012 at 12:31 PM, Branko Čibej wrote:
> On 16.02.2012 16:46, C. Michael Pilato wrote:
>> On 02/16/2012 05:50 AM, Branko Čibej wrote:
>>> On 15.02.2012 21:18, Greg Stein wrote:
And thinking on that: how does the client do inheritance in a
mixed-revision working copy? D@10
On 16.02.2012 16:46, C. Michael Pilato wrote:
> On 02/16/2012 05:50 AM, Branko Čibej wrote:
>> On 15.02.2012 21:18, Greg Stein wrote:
>>> And thinking on that: how does the client do inheritance in a
>>> mixed-revision working copy? D@10 inherits props from P, but the
>>> client has P@5. If there a
On 02/16/2012 05:50 AM, Branko Čibej wrote:
> On 15.02.2012 21:18, Greg Stein wrote:
>> And thinking on that: how does the client do inheritance in a
>> mixed-revision working copy? D@10 inherits props from P, but the
>> client has P@5. If there are changes in P@7, then the inherited
>> properties
On 15.02.2012 21:18, Greg Stein wrote:
> And thinking on that: how does the client do inheritance in a
> mixed-revision working copy? D@10 inherits props from P, but the
> client has P@5. If there are changes in P@7, then the inherited
> properties a likely wrong for D@10.
Reading this thread real
On Wed, Feb 15, 2012 at 14:29, C. Michael Pilato wrote:
> On 02/14/2012 06:48 PM, Paul Burba wrote:
>> It seems we are far from any consensus on inheritable properties. The
>> major sticking points seem to be as follows:
>>
>> -- 1 -- Performance: Server Side (a.k.a. "Is this ultimately an
>> exe
On 02/14/2012 06:48 PM, Paul Burba wrote:
> It seems we are far from any consensus on inheritable properties. The
> major sticking points seem to be as follows:
>
> -- 1 -- Performance: Server Side (a.k.a. "Is this ultimately an
> exercise in futility?")
[...]
> Looking at the server side, I mi
On Mon, Feb 13, 2012 at 12:05 PM, Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, Feb 13, 2012 at 17:52:01 +0100:
>> On 13.02.2012 17:09, Daniel Shahaf wrote:
>> > Thanks for your thoughts. One comment:
>> >
>> > Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100:
>> >> The idea is that
Branko Čibej wrote on Mon, Feb 13, 2012 at 17:52:01 +0100:
> On 13.02.2012 17:09, Daniel Shahaf wrote:
> > Thanks for your thoughts. One comment:
> >
> > Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100:
> >> The idea is that we'd always maintain the complete index, i.e., in order
> >> to
On 13.02.2012 17:09, Daniel Shahaf wrote:
> Thanks for your thoughts. One comment:
>
> Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100:
>> The idea is that we'd always maintain the complete index, i.e., in order
>> to determine if path@15 exists, one only needs to search the index for
>>
Thanks for your thoughts. One comment:
Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100:
> The idea is that we'd always maintain the complete index, i.e., in order
> to determine if path@15 exists, one only needs to search the index for
> (path, rev <= 15, !deleted) -- which is trivial i
On 12.02.2012 21:52, Branko Čibej wrote:
> The idea is that we'd always maintain the complete index, i.e., in order
> to determine if path@15 exists, one only needs to search the index for
> (path, rev <= 15, !deleted) -- which is trivial in a properly ordered
> index. (Yes, this assumes that we re
On 12.02.2012 17:58, Daniel Shahaf wrote:
> Stefan Fuhrmann wrote on Sun, Feb 12, 2012 at 13:57:23 +0100:
>> On 12.02.2012 06:27, Branko Čibej wrote:
>>> On 12.02.2012 02:52, Stefan Fuhrmann wrote:
>>>
The silly part of FSFS is that it does not optimize access
paths, yet, but stores chang
Stefan Fuhrmann wrote on Sun, Feb 12, 2012 at 13:57:23 +0100:
> On 12.02.2012 06:27, Branko Čibej wrote:
> >On 12.02.2012 02:52, Stefan Fuhrmann wrote:
> >
> >>The silly part of FSFS is that it does not optimize access
> >>paths, yet, but stores changes individually. The challenge
> >>is our two-di
On 08.02.2012 23:08, Paul Burba wrote:
On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann wrote:
On 07.02.2012 00:41, Greg Stein wrote:
On Mon, Feb 6, 2012 at 18:15, Paul Burba wrote:
Hi All,
There has long been a desire for Subversion to support some form of
inherited properties. Recently, w
On 12.02.2012 06:27, Branko Čibej wrote:
On 12.02.2012 02:52, Stefan Fuhrmann wrote:
The silly part of FSFS is that it does not optimize access
paths, yet, but stores changes individually. The challenge
is our two-dimensional key space and the fact that different
operations traverse the data al
On 12.02.2012 02:52, Stefan Fuhrmann wrote:
> The silly part of FSFS is that it does not optimize access
> paths, yet, but stores changes individually. The challenge
> is our two-dimensional key space and the fact that different
> operations traverse the data along different dimensions
> (e.g. log
On 10.02.2012 12:21, Branko Čibej wrote:
On 07.02.2012 22:24, Stefan Fuhrmann wrote:
On 07.02.2012 00:41, Greg Stein wrote:
In most data storage mechanisms for the repository, inheritable
properties are a performance killer.
I'm not sure that this is actually applicable to SVN
for two reasons:
On 07.02.2012 22:24, Stefan Fuhrmann wrote:
> On 07.02.2012 00:41, Greg Stein wrote:
>> In most data storage mechanisms for the repository, inheritable
>> properties are a performance killer.
>
> I'm not sure that this is actually applicable to SVN
> for two reasons:
> (1) we use deltification and
[snipping the parts I concur with]
Paul Burba wrote on Wed, Feb 08, 2012 at 17:08:57 -0500:
> On Mon, Feb 6, 2012 at 7:20 PM, Daniel Shahaf wrote:
> > Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500:
> >> Hi All,
> >>
> >> There has long been a desire for Subversion to support some form o
On Mon, Feb 6, 2012 at 7:20 PM, Daniel Shahaf wrote:
> Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500:
>> Hi All,
>>
>> There has long been a desire for Subversion to support some form of
>> inherited properties. Recently, while discussing a potential solution
>> for server dictated conf
On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann wrote:
> On 07.02.2012 00:41, Greg Stein wrote:
>>
>> In most data storage mechanisms for the repository, inheritable
>> properties are a performance killer.
>
>
> I'm not sure that this is actually applicable to SVN
> for two reasons:
> (1) we use d
On 07.02.2012 00:41, Greg Stein wrote:
In most data storage mechanisms for the repository, inheritable
properties are a performance killer.
I'm not sure that this is actually applicable to SVN
for two reasons:
(1) we use deltification and
(2) we often handle whole file trees
(1) causes us to d
Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500:
> Hi All,
>
> There has long been a desire for Subversion to support some form of
> inherited properties. Recently, while discussing a potential solution
> for server dictated configurations (see
> http://svn.haxx.se/dev/archive-2012-01/003
In most data storage mechanisms for the repository, inheritable
properties are a performance killer. Bill Tutt advised us against
inheritable properties years ago for exactly this reason. It is one of
the main reasons that we never implemented them. Good data modeling
for path-based inheritance is
42 matches
Mail list logo
