------------------------------ On Mon, Oct 27, 2014 06:38 GMT Eric Wong wrote:
>Which SVN version are you using? I'm cloning (currently on r373xx) >https://svn.r-project.org/R using --stdlayout and >unable to see memory growth of the git-svn Perl process beyond 40M >(on a 32-bit system). > >I also tried http:// (not https), svn+ssh:// on my local (64-bit) system >and did not see memory growth, either: > > http://mid.gmane.org/20141027014033.ga4...@dcvr.yhbt.net > >I'm using svn 1.6.17 on Debian stable in all cases. The memory consumption does seem to go up a good deal after r48xxx -ish (the total being about 67xxx-ish now), when there are a fair number of branches. Seeing as you seem to be able to make the memory consumption drops further, I'll rebuild git with dropping/adding those patches now. I also just realised "/usr/bin/time -v git svn fetch --all" also includes the periodic auto- garbage collection from git itself if fetching more than a number of commits, so may not be accurate once git svn's memory consumption drops below a certain level. Is there any way of coping with that? I made a 3rd clone yesterday - it took 8 hours 15 minutes, and Command being timed: "git svn fetch --all" User time (seconds): 6897.80 System time (seconds): 18853.08 Percent of CPU this job got: 86% Elapsed (wall clock) time (h:mm:ss or m:ss): 8:14:00 ... Maximum resident set size (kbytes): 675436 and fetching the next 8 commits: $ /usr/bin/time -v git svn fetch --all M doc/NEWS.Rd r66871 = 0a7f50fc04dee174229513a0d80fecfcd12975ca (refs/remotes/trunk) ... M doc/manual/R-exts.texi r66879 = ede68f65df714c3ba283579d85105393c1eccc80 (refs/remotes/trunk) Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. Command being timed: "git svn fetch --all" User time (seconds): 856.82 System time (seconds): 29.78 Percent of CPU this job got: 98% Elapsed (wall clock) time (h:mm:ss or m:ss): 15:03.39 ... Maximum resident set size (kbytes): 791088 and quite similar against the 2nd clone, but against the first clone (which were created by fetching every few days over a few years): Command being timed: "git svn fetch --all" User time (seconds): 518.00 System time (seconds): 28.62 Percent of CPU this job got: 98% Elapsed (wall clock) time (h:mm:ss or m:ss): 9:16.84 ... Maximum resident set size (kbytes): 403160 So it seems the first clone is rather different from the recent ones. I haven't got round to compare the branches yet - it is actually easier than I thought, since I only need to compare the branch HEADs. (I already mentioned that trunk is different, due to a blank vs 3 word commit message about 2 years ago - I reckon I might see similar issues in the other branches - I'll go and write a script to check that now). All recent fetch were done with git 2.1.0 patched with the 6 patches I mentioned, on fedora 20 x86_64. BTW, I have been meaning to ask - are you the same "Eric Wong" who maintained some chinese packages on Debian some years ago? :-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
