Hi guys,
Any further interest on this scalability problem or should I move on?
Thanks,
Uri
On Thu, Nov 8, 2012 at 5:35 PM, Uri Moszkowicz u...@4refs.com wrote:
I tried on the local disk as well and it didn't help. I managed to
find a SUSE11 machine and tried it there but no luck so I think we
On Wed, Nov 07, 2012 at 11:32:37AM -0600, Uri Moszkowicz wrote:
#4 parse_object (sha1=0xb0ee98
\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D) at
object.c:212
#5 0x004ae9ec in handle_one_ref (path=0xb0eec0
refs/tags/removed, sha1=0xb0ee98
I tried the patch but it doesn't appear to have helped :( Clone time
with it was ~32m.
Do you all by any chance have a tool to obfuscate a repository?
Probably I still wouldn't be permitted to distribute it but might make
the option slightly more palatable. Anything else that I can do to
help
On Thu, Nov 08, 2012 at 11:20:29AM -0600, Uri Moszkowicz wrote:
I tried the patch but it doesn't appear to have helped :( Clone time
with it was ~32m.
That sounds ridiculously long.
Do you all by any chance have a tool to obfuscate a repository?
Probably I still wouldn't be permitted to
I'm using RHEL4. Looks like perf is only available with RHEL6.
heads: 308
tags: 9614
Looking up the tags that way took a very long time by the way. git
tag | wc -l was much quicker. I've already pruned a lot of tags to
get to this number as well. The original repository had ~37k tags
since we
On Thu, Nov 08, 2012 at 03:49:32PM -0600, Uri Moszkowicz wrote:
I'm using RHEL4. Looks like perf is only available with RHEL6.
Yeah, RHEL4 is pretty ancient; I think it predates the invention of
perf.
heads: 308
tags: 9614
Looking up the tags that way took a very long time by the way. git
I ran git cat-file commit some-tag for every tag. They seem to be
roughly uniformly distributed between 0s and 2s and about 2/3 of the
time seems to be system. My disk is mounted over NFS so I tried on the
local disk and it didn't make a difference.
I have only one 1.97GB pack. I ran git gc
On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote:
I ran git cat-file commit some-tag for every tag. They seem to be
roughly uniformly distributed between 0s and 2s and about 2/3 of the
time seems to be system. My disk is mounted over NFS so I tried on the
local disk and it
I tried on the local disk as well and it didn't help. I managed to
find a SUSE11 machine and tried it there but no luck so I think we can
eliminate NFS and OS as significant factors now.
I ran with perf and here's the report:
ESC[31m69.07%ESC[m git /lib64/libc-2.11.1.so
It all goes to pack_refs() in write_remote_refs called from
update_remote_refs().
On Tue, Oct 23, 2012 at 11:29 PM, Nguyen Thai Ngoc Duy
pclo...@gmail.com wrote:
On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz u...@4refs.com wrote:
I have a large repository which I ran git gc --aggressive on
I have a large repository which I ran git gc --aggressive on that
I'm trying to clone on a local file system. I would expect it to
complete very quickly with hard links but it's taking about 6min to
complete with no checkout (git clone -n). I see the message Clining
into 'repos'... done. appear
On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz u...@4refs.com wrote:
I have a large repository which I ran git gc --aggressive on that
I'm trying to clone on a local file system. I would expect it to
complete very quickly with hard links but it's taking about 6min to
complete with no checkout
12 matches
Mail list logo
