Philip Martin writes:
> Philip Martin writes:
>
>> Update with no changes on NFS disk:
>>
>> 1.6: 2s
>> 1.7: 50s
>
> With the recent bump-post-update changes that 50s has become 23s.
With the recent report-revisions per-dir changes that 23s has become 7.5s.
--
Philip
Philip Martin writes:
> Update with no changes on NFS disk:
>
> 1.6: 2s
> 1.7: 50s
With the recent bump-post-update changes that 50s has become 23s.
--
Philip
Mark Phippard writes:
> I think it should be faster overall. Like Ivan, I think status and
> update on large working copies are areas where I would like to see
> show significant improvements.
>
> I can live with some operations being comparable to 1.6. I do not
> think we can accept any major
On 12.03.2011 19:41, Mark Phippard wrote:
> On Sat, Mar 12, 2011 at 12:49 PM, Justin Erenkrantz
> wrote:
>> On Fri, Mar 11, 2011 at 4:11 PM, Mark Phippard wrote:
>>> I think we have to get this work done soon. We cannot release with
>>> performance like it is. How do we define the scope of the
On Sat, Mar 12, 2011 at 12:49 PM, Justin Erenkrantz
wrote:
> On Fri, Mar 11, 2011 at 4:11 PM, Mark Phippard wrote:
>> I think we have to get this work done soon. We cannot release with
>> performance like it is. How do we define the scope of the work that
>> needs to be done so that we can divi
On Sat, Mar 12, 2011 at 20:49, Justin Erenkrantz wrote:
> On Fri, Mar 11, 2011 at 4:11 PM, Mark Phippard wrote:
>> I think we have to get this work done soon. We cannot release with
>> performance like it is. How do we define the scope of the work that
>> needs to be done so that we can divide
On Fri, Mar 11, 2011 at 4:11 PM, Mark Phippard wrote:
> I think we have to get this work done soon. We cannot release with
> performance like it is. How do we define the scope of the work that
> needs to be done so that we can divide and conquer and get these
> changes in place?
It sounds like
On Fri, Mar 11, 2011 at 02:13:05PM -0500, Greg Stein wrote:
> On IRC, there was a discussion about the wc_db API. In particular
> whether to have lots of query functions, or to have the caller sort it
> out. As Bert noted, my original intent was to provide the caller with
> enough information and l
2011/3/11 Branko Čibej :
> On 11.03.2011 20:13, Greg Stein wrote:
>> I also don't like to see structures like svn_wc__db_info_t. We had a
>> big problem with the entry_t, and things like info_t will continue to
>> propagate that broken model. By definition, to use that structure a
>> query must be
On 11.03.2011 20:13, Greg Stein wrote:
> I also don't like to see structures like svn_wc__db_info_t. We had a
> big problem with the entry_t, and things like info_t will continue to
> propagate that broken model. By definition, to use that structure a
> query must be done against both NODES and ACT
10 matches
Mail list logo