On Tue, May 8, 2012 at 1:11 PM, C. Michael Pilato <cmpilato@...> wrote:
> On 05/08/2012 01:03 PM, Mark Phippard wrote:
>> On Tue, May 8, 2012 at 12:59 PM, C. Michael Pilato <cmpilato@...> wrote:
>>> Mark, can you see if this (and previous commits I've made) fixes the file
>>> handle abuse problem you reported?
>>> I tested this locally using "ulimit -n 200" to reduce the file handle limit
>>> on my box from 8192 to 200. Before this change, I saw the same error you
>>> did. Afterward, no error. Hoping you experience the same.
>> Confirmed. This resolves it for me too.
> Sweet. Thanks!
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
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?