[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1335639 - /subversion/trunk/subversion/libsvn_wc/adm_ops.c

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 8 May 2012 14:51:14 -0400

On Tue, May 8, 2012 at 2:45 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 05/08/2012 02:34 PM, Mark Phippard wrote:
>> Now that I can run the test I wanted, the performance improvement is
>> pretty nice.  Checking out our code goes from 1m35s down to 0m44s.  I
>> cannot help but think that number should still be a lot lower though.
>> This scenario seems like it would be very similar to what a Git
>> checkout would do now, probably even less work has to be done.  I do
>> not have a Git-svn version of our codebase to test with, but I am
>> guessing a Git checkout of our code would be less than 10 seconds.  So
>> it might be an indication we could be doing more optimization in our
>> libraries.
>>
>> That said, I still think it is a nice improvement and I imagine it
>> would scale up and down based on size and number of files.
>>
>> Does anyone have a git version of our tree they could try this with?
>> How long does it take git to materialize a working copy of our trunk?
>
> As I said before, I suspect your numbers would be much lower if I wasn't
> sending HEAD requests for each file.  Unfortunately, ra_serf is depending on
> the ordering of the pipelined requests (PROPFIND results for a given path
> must be processed before the contents of the file are fetched), and I don't
> know how to make that happen without ripping apart the pipelining machinery
> and doing something custom there.

I can get that fixed (at some point). A little hand-wavey magic in the
callbacks, and we'll be good to go.

Would you mind opening an issue (assigned or cc'd to me) to track
that? It certainly isn't a blocker, but would be a very nice
enhancement.

Thanks,
-g
Received on 2012-05-08 20:51:45 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.