On Thu, Mar 17, 2011 at 22:10, C. Michael Pilato wrote:
> On 03/17/2011 03:43 PM, Greg Stein wrote:
>> Dude. If you want to delete *one* prop from the dav_cache, then just torch
>> them all (ie. set to null). HTTPv2 does not use them. HTTPv1 only uses the
>> vsn URL. And it is a cache.
>>
>> So do
On 03/17/2011 03:43 PM, Greg Stein wrote:
> Dude. If you want to delete *one* prop from the dav_cache, then just torch
> them all (ie. set to null). HTTPv2 does not use them. HTTPv1 only uses the
> vsn URL. And it is a cache.
>
> So don't be tricky. Blast the entire dav_cache rather than tweak it.
Greg Stein wrote:
> I'd thought about removing them long ago, or at least moving them out into
> helper/utility functions. So I say nuke them!
Gone. r1082690. Thanks.
- Julian
> On Mar 17, 2011 5:29 PM, "Julian Foad" wrote:
> > Mike, Greg,
> >
> > Is it OK with you if I remove the single-pro
Dude. If you want to delete *one* prop from the dav_cache, then just torch
them all (ie. set to null). HTTPv2 does not use them. HTTPv1 only uses the
vsn URL. And it is a cache.
So don't be tricky. Blast the entire dav_cache rather than tweak it.
On Mar 17, 2011 6:40 PM, "C. Michael Pilato" wrot
I'd thought about removing them long ago, or at least moving them out into
helper/utility functions. So I say nuke them!
On Mar 17, 2011 5:29 PM, "Julian Foad" wrote:
> Mike, Greg,
>
> Is it OK with you if I remove the single-prop-get WC DB APIs, which are
> unused? In light of what you're talking
That's fine with me. I'm actually off playing with custom SQLite functions
at the moment, trying to find a way to write statements like "go delete all
the version-url properties from the dav_cache for all the items in and under
TARGET".
On 03/17/2011 01:29 PM, Julian Foad wrote:
> Mike, Greg,
>
Mike, Greg,
Is it OK with you if I remove the single-prop-get WC DB APIs, which are
unused? In light of what you're talking about I just want to check this
won't be stepping on your toes.
[[[
Remove unused single-prop-get functions from the WC DB API, because they
were just clutter in the API.
On 03/17/2011 09:57 AM, Julian Foad wrote:
> What both of you say makes sense. What I can add is an observation that
> separating the props out into the schema would appear to benefit the
> efficiency of bulk-data operations such as "svn pget -R svn:needs-lock".
> I don't think it would have much
What both of you say makes sense. What I can add is an observation that
separating the props out into the schema would appear to benefit the
efficiency of bulk-data operations such as "svn pget -R svn:needs-lock".
I don't think it would have much effect on per-node operations such as
"update", "me
On Mar 16, 2011 5:34 PM, "C. Michael Pilato" wrote:
>
> On 03/16/2011 01:17 PM, Greg Stein wrote:
> > On Wed, Mar 16, 2011 at 12:59, C. Michael Pilato
wrote:
> >> ...
> >> to manage at least the "read" subset of these operations. But I find
myself
> >> wondering if we wouldn't be better served b
On 03/16/2011 01:17 PM, Greg Stein wrote:
> On Wed, Mar 16, 2011 at 12:59, C. Michael Pilato wrote:
>> ...
>> to manage at least the "read" subset of these operations. But I find myself
>> wondering if we wouldn't be better served by having a properties table with
>> rows for, I dunno: wc_id, lo
On Wed, Mar 16, 2011 at 12:59, C. Michael Pilato wrote:
>...
> to manage at least the "read" subset of these operations. But I find myself
> wondering if we wouldn't be better served by having a properties table with
> rows for, I dunno: wc_id, local_relpath, property_name, property_value.
>...
[Begging your pardon for not being able to speak with confident accuracy
about the inner workings of WC-NG.]
Today, while trying to get an overview of the various ways in which
svn_wc__node_walk_children() was used, I found some patterns that seem, to
me at least, to cry out for better database sc
13 matches
Mail list logo
