{"thread":{"id":"37824","subject":"Re: Anomaly with the new code - Re: git-svn performance","startedAt":"2014-10-27T23:26:28Z","lastAt":"2014-10-30T23:08:31Z","messageCount":14,"participants":["Hin-Tak Leung","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"251137","messageId":"1414452388.89217.YahooMailBasic@web172306.mail.ir2.yahoo.com","threadId":"37824","inReplyTo":null,"subject":"Re: Anomaly with the new code - Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-27T23:26:28Z","receivedAt":"2014-10-27T23:26:28Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"------------------------------\nOn Mon, Oct 27, 2014 16:56 GMT Eric Wong wrote:\n\n>Eric Wong wrote:\n>> Which SVN version are you using?  I'm cloning (currently on r373xx)\n>> https://svn.r-project.org/R using --stdlayout and\n>> unable to see memory growth of the git-svn Perl process beyond 40M\n>> (on a 32-bit system).\n>\n>git-svn hit 45M and took 11:44 to finish.   My ping times to\n>svn.r-project.org is around 150ms (I'm running this from a server in\n>Fremont, California).  I'll keep the repo around and periodically fetch\n>to see how it runs.\n\nI'll apply the 10 patches against 2.1.0 and see then. As I wrote\nin my last reply, my 3rd clone took about 8 hours to finish,\nand the max resident size is about 700MB (according to GNU \"time\").\n\nAFAIK the hosting server is in northern Europe (Copahagen?), I think,\nso it is supposed to be faster for me fetching from UK.\n"},{"id":"251140","messageId":"1414474807.30075.YahooMailBasic@web172303.mail.ir2.yahoo.com","threadId":"37824","inReplyTo":"1414452388.89217.YahooMailBasic@web172306.mail.ir2.yahoo.com","subject":"differences between old clone and new Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-28T05:40:07Z","receivedAt":"2014-10-28T05:40:07Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"To compare the old clone with the new, I did:\n\ngit branch -r | sort | xargs -n 1 git log --decorate=full -n 1\n\nIt turned out other than the empty vs 3 word commit messages\nabout two years ago on trunk (which are inherited in all the newer\nbranches), there are two other groups of differences.\n\nOne branch on the old clone has an extra merge from trunk (\nand some extra trunk commits) listed in 'git log', while\nanother branch has the exact opposite - on the old clone\nhas one fewer merge.\n\nI see the merge seem to be genuine - the subversion log\noften says so e.g. \"ported from rXXX from trunk\", but\nthe extra/missing pattern isn't consistent.\n\nSo the histories are largely the same, except due to the \nextra merge, don't have the same sha1 sums.\n"},{"id":"251142","messageId":"20141028074104.GA7762@dcvr.yhbt.net","threadId":"37824","inReplyTo":"1414474807.30075.YahooMailBasic@web172303.mail.ir2.yahoo.com","subject":"Re: differences between old clone and new Re: git-svn performance","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2014-10-28T07:41:04Z","receivedAt":"2014-10-28T07:41:04Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Hin-Tak Leung wrote:\n> To compare the old clone with the new, I did:\n> \n> git branch -r | sort | xargs -n 1 git log --decorate=full -n 1\n> \n> It turned out other than the empty vs 3 word commit messages\n> about two years ago on trunk (which are inherited in all the newer\n> branches), there are two other groups of differences.\n> \n> One branch on the old clone has an extra merge from trunk (\n> and some extra trunk commits) listed in 'git log', while\n> another branch has the exact opposite - on the old clone\n> has one fewer merge.\n> \n> I see the merge seem to be genuine - the subversion log\n> often says so e.g. \"ported from rXXX from trunk\", but\n> the extra/missing pattern isn't consistent.\n\nSo both merges are correct, but we lose one, and gain one?\nI'll try to check more closely tomorrow. Can you point out\nthe exact revisions in the R repo? Thanks.\n\n> So the histories are largely the same, except due to the \n> extra merge, don't have the same sha1 sums.\n"},{"id":"251143","messageId":"20141028074534.GB7762@dcvr.yhbt.net","threadId":"37824","inReplyTo":"1414452388.89217.YahooMailBasic@web172306.mail.ir2.yahoo.com","subject":"Re: Anomaly with the new code - Re: git-svn performance","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2014-10-28T07:45:34Z","receivedAt":"2014-10-28T07:45:34Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Hin-Tak Leung wrote:\n> >Eric Wong wrote:\n> >> Which SVN version are you using?  I'm cloning (currently on r373xx)\n> >> https://svn.r-project.org/R using --stdlayout and\n> >> unable to see memory growth of the git-svn Perl process beyond 40M\n> >> (on a 32-bit system).\n> >\n> >git-svn hit 45M and took 11:44 to finish.   My ping times to\n> >svn.r-project.org is around 150ms (I'm running this from a server in\n> >Fremont, California).  I'll keep the repo around and periodically fetch\n> >to see how it runs.\n> \n> I'll apply the 10 patches against 2.1.0 and see then. As I wrote\n> in my last reply, my 3rd clone took about 8 hours to finish,\n> and the max resident size is about 700MB (according to GNU \"time\").\n\nThe \"time\" command is not a good measurement since it includes child\nprocess memory use (which may be file-backed mmap for git repack or\n\"git cat-file --batch\"). My measurements are just the RSS of the\ngit-svn Perl process (from \"ps aux\" or VmRSS in /proc/$PID/status\non Linux)\n"},{"id":"251172","messageId":"1414539214.3654.YahooMailBasic@web172306.mail.ir2.yahoo.com","threadId":"37824","inReplyTo":"1414474807.30075.YahooMailBasic@web172303.mail.ir2.yahoo.com","subject":"Regression and failure to clone/fetch with new code Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-28T23:33:34Z","receivedAt":"2014-10-28T23:33:34Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"Hi, I patched my system git with the recent git-svn improvements, and just use\nit for general use; so theses are the patches, against 2.1.0.\n\n0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch\n0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patch\n0003-git-svn-reduce-check_cherry_pick-cache-overhead.patch\n0004-git-svn-cache-only-mergeinfo-revisions.patch\n0005-git-svn-remove-mergeinfo-rev-caching.patch\n0006-git-svn.txt-advertise-pushurl-with-dcommit.patch\n0007-git-svn-reload-RA-every-log-window-size.patch\n0008-git-svn-remove-unnecessary-DESTROY-override.patch\n0009-git-svn-save-a-little-memory-as-fetch-progresses.patch\n0010-git-svn-disable-_rev_list-memoization.patch\n\ntrying to do this:\ngit svn clone http://www.virtualbox.org/svn/vbox/trunk vbox\n\n(there is no publicly visible branches, so it is just a straight-forward single-branch clone).\n\naborts with \n\n---------------\n\tM\tsrc/VBox/Main/HostImpl.cpp\nIncorrect parameters given: Could not convert '%ld' into a number at /usr/share/perl5/vendor_perl/Git/SVN.pm line 1711.\n\n$ git svn fetch --all\nIndex mismatch: d6c75bc195b1daad647322e2cc025bd31265c6b9 != 3927d05f6ab037fcf2b4d964c9633efade037d1b\nrereading a65b5fc0077c2fa80a344833b65ac19ff4ae88b6\n\tM\tsrc/VBox/Main/HostImpl.cpp\nIncorrect parameters given: Could not convert '%ld' into a number at /usr/share/perl5/vendor_perl/Git/SVN.pm line 1711.\n----------------\n\nI have never seen such behavior before, and seeing as the lines indicated are in\na routine called \"mergeinfo_changes\", and recently added/changed by\nquite a few of the patches, I started reverting from the back in this order: #5, #4, #2, #1 \nand tried again between each revert. And it finally allows me to fetch again after\nreverting #1.\n\nI don't see any %ld close by, but presumably this is enough information for somebody else\nto try. The platform is linux x86_64. (mostly fedora 20 but with a lot of additional\nchanges like a newer gnome than shipped, etc so probably not really fc20) \n"},{"id":"251173","messageId":"1414540742.41763.YahooMailBasic@web172305.mail.ir2.yahoo.com","threadId":"37824","inReplyTo":"20141028074104.GA7762@dcvr.yhbt.net","subject":"Re: differences between old clone and new Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-28T23:59:02Z","receivedAt":"2014-10-28T23:59:02Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"On Tue, 28/10/14, Eric Wong wrote:\n\n> So both merges\n are correct, but we lose one, and gain one?\n I'll try to check more closely tomorrow. \n Can you point out\n the exact revisions in the\n R repo?  Thanks.\n\n\nThe missing merge on branch \"R-2-14-branch\" is:\n\ncommit 93af4d4cc3a5e0039944dd4e340d26995be8a252\nMerge: 121990f 6ff1b87\nAuthor: ripley \nDate: Wed Feb 22 13:45:34 2012 +0000\n\n port r58453 from trunk\n\n git-svn-id: https://svn.r-project.org/R/branches/R-2-14-branch@58454 00db46b3-68df-0310-9c12-caf00c1e9a41\n\n\n\n121990f is R-2-14-branch@58449, 6ff1b87 is trunk@58453, but the two branches\nare only identical up to and including R-2-14-branch@57129 - \ni.e. trunk@57130 appears in my old clone's \"R-2-14-branch\" git log but not in the new clone's.\n\nThe extra merge in the new clone is in branch \"djm-parseRd\":\n\ncommit 6d93330f7637eb4da81adaea58454c6b43da1c65\nMerge: f503a9d 23deade\nAuthor: murdoch \nDate: Thu Nov 13 14:24:17 2008 +0000\n\n Update from trunk to r46923\n \n git-svn-id: https://svn.r-project.org/R/branches/djm-parseRd@46925 00db46b3-68df-0310-9c12-caf00c1e9a41\n\nYou can look up f503a9d (djm-parseRd@46922) and 23deade (trunk@46923) yourself.\nThe two branches' git log agree up to and including djm-parseRd@46659 .\n\nHmm, the new \"djm-parseRd\" branch actually have *two* extra merges,\nthe earlier extra is:\n\ncommit 1e8174c797ba8471d604e89e4d614ad969b93b72\nMerge: 55a1d9b 72744ab\nAuthor: murdoch \nDate: Tue Nov 11 21:17:06 2008 +0000\n\n Merge trunk changes to r46902\n \n git-svn-id: https://svn.r-project.org/R/branches/djm-parseRd@46906 00db46b3-68df-0310-9c12-caf00c1e9a41\n"},{"id":"251188","messageId":"20141029192352.GA32032@dcvr.yhbt.net","threadId":"37824","inReplyTo":"1414539214.3654.YahooMailBasic@web172306.mail.ir2.yahoo.com","subject":"Re: Regression and failure to clone/fetch with new code Re: git-svn performance","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2014-10-29T19:23:52Z","receivedAt":"2014-10-29T19:23:52Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Hin-Tak Leung wrote:\n> Hi, I patched my system git with the recent git-svn improvements, and just use\n> it for general use; so theses are the patches, against 2.1.0.\n> \n> 0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch\n> 0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patch\n> 0003-git-svn-reduce-check_cherry_pick-cache-overhead.patch\n> 0004-git-svn-cache-only-mergeinfo-revisions.patch\n> 0005-git-svn-remove-mergeinfo-rev-caching.patch\n> 0006-git-svn.txt-advertise-pushurl-with-dcommit.patch\n> 0007-git-svn-reload-RA-every-log-window-size.patch\n> 0008-git-svn-remove-unnecessary-DESTROY-override.patch\n> 0009-git-svn-save-a-little-memory-as-fetch-progresses.patch\n> 0010-git-svn-disable-_rev_list-memoization.patch\n> \n> trying to do this:\n> git svn clone http://www.virtualbox.org/svn/vbox/trunk vbox\n> \n> (there is no publicly visible branches, so it is just a straight-forward single-branch clone).\n> \n> aborts with \n> \n> ---------------\n> \tM\tsrc/VBox/Main/HostImpl.cpp\n> Incorrect parameters given: Could not convert '%ld' into a number at /usr/share/perl5/vendor_perl/Git/SVN.pm line 1711.\n> \n> $ git svn fetch --all\n> Index mismatch: d6c75bc195b1daad647322e2cc025bd31265c6b9 != 3927d05f6ab037fcf2b4d964c9633efade037d1b\n> rereading a65b5fc0077c2fa80a344833b65ac19ff4ae88b6\n> \tM\tsrc/VBox/Main/HostImpl.cpp\n> Incorrect parameters given: Could not convert '%ld' into a number at /usr/share/perl5/vendor_perl/Git/SVN.pm line 1711.\n> ----------------\n> \n> I have never seen such behavior before, and seeing as the lines indicated are in\n> a routine called \"mergeinfo_changes\", and recently added/changed by\n> quite a few of the patches, I started reverting from the back in this order: #5, #4, #2, #1 \n> and tried again between each revert. And it finally allows me to fetch again after\n> reverting #1.\n\nMe neither, this is new bug to me. I cannot reproduce it, either. Which\nrevision did you hit this on? I completed your vbox trunk clone without\nany problems on my side (Debian i386, SVN 1.6.17).\n\nCan you try the following to dump out the parameters passed to\nmergeinfo_changes?\n\n--- a/perl/Git/SVN.pm\n+++ b/perl/Git/SVN.pm\n@@ -1695,8 +1695,10 @@ sub parents_exclude {\n }\n \n # Compute what's new in svn:mergeinfo.\n+use Data::Dumper;\n sub mergeinfo_changes {\n \tmy ($self, $old_path, $old_rev, $path, $rev, $mergeinfo_prop) = @_;\n+\tprint STDERR Dumper(\\@_);\n \tmy %minfo = map {split \":\", $_ } split \"\\n\", $mergeinfo_prop;\n \tmy $old_minfo = {};\n \n\nBtw, I missed part of your other email, but no, I never maintained any\nChinese packages in Debian.\n\n> I don't see any %ld close by, but presumably this is enough information for somebody else\n> to try. The platform is linux x86_64. (mostly fedora 20 but with a lot of additional\n> changes like a newer gnome than shipped, etc so probably not really fc20) \n> \n"},{"id":"251200","messageId":"1414627570.41692.YahooMailBasic@web172306.mail.ir2.yahoo.com","threadId":"37824","inReplyTo":"20141029192352.GA32032@dcvr.yhbt.net","subject":"Re: Regression and failure to clone/fetch with new code Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-30T00:06:10Z","receivedAt":"2014-10-30T00:06:10Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"Argh, sorry. I thought I included the info but I didn't.\n\ngit 2.1.0 + 10 patches aborts after trunk@28923 (i.e. failing to fetch 28924);\nif I revert the patches in that order (#5,#4,#2, #1) and retry in the middle,\nI have to revert all 4 to get 'git svn fetch' to continue on to 28924.\n\nI tried --stdlayout (it seems that there were branches, but just merged and \"deleted\"\naccording to the web code browsing interface) but it failed at the same revision.\n\nI'll try the data dump and see what it gives me...\n\nWhat do you think were missing in my e-mails? The differences of new clone against old\nis a missing merge in at R-2-14-branch@58454 , and two extra merges at\ndjm-parseRd@46925 and djm-parseRd@46906 .\n\n--------------------------------------------\nOn Wed, 29/10/14, Eric Wong wrote:\n\n Subject: Re: Regression and failure to clone/fetch with new code Re: git-svn performance\n To: \"Hin-Tak Leung\" \n Cc: stoklund@2pi.dk, fabian.schmied@gmail.com, git@vger.kernel.org, sam@vilain.net, stevenrwalter@gmail.com, waste.manager@gmx.de, amyrick@apple.com\n Date: Wednesday, 29 October, 2014, 20:23\n \n Hin-Tak Leung \n wrote:\n > Hi, I patched my system git with\n the recent git-svn improvements, and just use\n > it for general use; so theses are the\n patches, against 2.1.0.\n > \n >\n 0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch\n >\n 0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patch\n >\n 0003-git-svn-reduce-check_cherry_pick-cache-overhead.patch\n >\n 0004-git-svn-cache-only-mergeinfo-revisions.patch\n >\n 0005-git-svn-remove-mergeinfo-rev-caching.patch\n >\n 0006-git-svn.txt-advertise-pushurl-with-dcommit.patch\n >\n 0007-git-svn-reload-RA-every-log-window-size.patch\n >\n 0008-git-svn-remove-unnecessary-DESTROY-override.patch\n >\n 0009-git-svn-save-a-little-memory-as-fetch-progresses.patch\n >\n 0010-git-svn-disable-_rev_list-memoization.patch\n > \n > trying to do\n this:\n > git svn clone http://www.virtualbox.org/svn/vbox/trunk\n vbox\n > \n > (there\n is no publicly visible branches, so it is just a\n straight-forward single-branch clone).\n >\n \n > aborts with \n > \n > ---------------\n >\n     M    src/VBox/Main/HostImpl.cpp\n > Incorrect parameters given: Could not\n convert '%ld' into a number at\n /usr/share/perl5/vendor_perl/Git/SVN.pm line 1711.\n > \n > $ git svn fetch\n --all\n > Index mismatch:\n d6c75bc195b1daad647322e2cc025bd31265c6b9 !=\n 3927d05f6ab037fcf2b4d964c9633efade037d1b\n > rereading\n a65b5fc0077c2fa80a344833b65ac19ff4ae88b6\n >     M   \n src/VBox/Main/HostImpl.cpp\n > Incorrect\n parameters given: Could not convert '%ld' into a\n number at /usr/share/perl5/vendor_perl/Git/SVN.pm line\n 1711.\n > ----------------\n > \n > I have never seen\n such behavior before, and seeing as the lines indicated are\n in\n > a routine called\n \"mergeinfo_changes\", and recently added/changed\n by\n > quite a few of the patches, I\n started reverting from the back in this order: #5, #4, #2,\n #1 \n > and tried again between each\n revert. And it finally allows me to fetch again after\n > reverting #1.\n \n Me neither, this is new bug to me.  I cannot\n reproduce it, either.  Which\n revision did\n you hit this on?  I completed your vbox trunk clone\n without\n any problems on my side (Debian\n i386, SVN 1.6.17).\n \n Can you\n try the following to dump out the parameters passed to\n mergeinfo_changes?\n \n --- a/perl/Git/SVN.pm\n +++\n b/perl/Git/SVN.pm\n @@ -1695,8 +1695,10 @@ sub\n parents_exclude {\n }\n \n # Compute what's new in svn:mergeinfo.\n +use Data::Dumper;\n sub\n mergeinfo_changes {\n     my ($self,\n $old_path, $old_rev, $path, $rev, $mergeinfo_prop) = @_;\n +    print STDERR Dumper(\\@_);\n     my %minfo = map {split \":\",\n $_ } split \"\\n\", $mergeinfo_prop;\n \n     my $old_minfo = {};\n \n \n Btw, I missed part of your\n other email, but no, I never maintained any\n Chinese packages in Debian.\n \n > I don't see any %ld close by, but\n presumably this is enough information for somebody else\n > to try. The platform is linux x86_64.\n (mostly fedora 20 but with a lot of additional\n > changes like a newer gnome than shipped,\n etc so probably not really fc20) \n > \n \n"},{"id":"251201","messageId":"20141030002136.GA31920@dcvr.yhbt.net","threadId":"37824","inReplyTo":"1414540742.41763.YahooMailBasic@web172305.mail.ir2.yahoo.com","subject":"Re: differences between old clone and new Re: git-svn performance","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2014-10-30T00:21:36Z","receivedAt":"2014-10-30T00:21:36Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Hin-Tak Leung wrote:\n> On Tue, 28/10/14, Eric Wong wrote:\n> \n> > So both merges\n> are correct, but we lose one, and gain one?\n> I'll try to check more closely tomorrow. \n> Can you point out\n> the exact revisions in the\n> R repo?  Thanks.\n> \n> \n> The missing merge on branch \"R-2-14-branch\" is:\n> \n> commit 93af4d4cc3a5e0039944dd4e340d26995be8a252\n> Merge: 121990f 6ff1b87\n> Author: ripley \n> Date: Wed Feb 22 13:45:34 2012 +0000\n> \n> port r58453 from trunk\n> \n> git-svn-id: https://svn.r-project.org/R/branches/R-2-14-branch@58454 00db46b3-68df-0310-9c12-caf00c1e9a41\n\nI'm curious if you can tell me which version of git-svn you used to get\nthat as a merge commit. git-svn mergeinfo handling has changed\n(hopefully improved) over the years, so some differences in history\ncan be (unfortunately) expected, I think.\n\nI cannot reproduce your original merge on Junio's current master. Using\nJunio's master[1] without any recent git-svn changes, a partial clone\ndoing:\n\n git svn clone -s -r52000:58600 svn+ssh://127.0.0.1/path/to/my/R-mirror\n\n...causes the merges in r58454 to be ignored as cherry-picks, too.\nI suspect it's correct for git-svn to ignore those as cherry-picks\nnowadays.\n\nHere's a snippet of what I see from the above command:\n----------------------------------8<-----------------------------------\nr58452 = ebf3a1ca312ca7cc03dc2387d86491a0cdc95bad (refs/remotes/origin/trunk)\n\tM\tsrc/library/base/man/Primitive.Rd\n\tM\tsrc/main/names.c\n\tM\tdoc/NEWS.Rd\nr58453 = 05b55eee9e6bed628873d34261e54c70f87a3736 (refs/remotes/origin/trunk)\n\tM\tdoc/NEWS.Rd\n\tM\tsrc/library/base/man/Primitive.Rd\n\tM\tsrc/main/names.c\nW:svn cherry-pick ignored (/branches/R-2-12-branch:52939,54476,55265) - missing 492 commit(s) (eg df9d875de507ac51932c0ed980392e8262f98b31)\nW:svn cherry-pick ignored (/branches/R-2-13-branch:55265,55432) - missing 231 commit(s) (eg cad052d416d9b8a9dfbfb2ae7bf85c39306c67bb)\nW:svn cherry-pick ignored (/trunk:57183,57204-57205,57242,57259,57314,57316,57321,57370,57411,57428,57430,57432,57438,57440,57484,57489-57490,57579,57589,57604,57614-57618,57625,57679,57681,57687,57738,57741,57744-57745,57747,57752,57758,57761,57763,57765,57767,57769,57771,57790,57793,57803,57812,57814,57816,57826-57827,57836,57840-57841,57844,57846,57851,57853,57856,57861-57862,57867,57880,57884,57890,57893,57895,57900,57904,57908,57913,57920,57936,57939-57941,57950,57952,57959,57964,57970,57975,57977,57981,57987,58006,58008,58037,58039,58042,58047,58052,58056,58058,58066-58067,58082,58084,58089,58094,58098,58100,58107,58126,58129,58135,58142,58161,58178,58182,58187,58195,58204,58213,58217,58221,58225,58228,58232,58234,58239,58248,58253,58265,58269,58272,58274,58276,58278,58282,58284,58288,58294,58296,58305,58312,58314,58318,58324,58326,58328,58332,58334,58340,58346,58348,58353,58355,58357,58359,58361,58373,58378,58381,58386,58388,58392,58395,58397,58405,58412,58415,58429,58435,58437,58439,58453) - missing 716 commit(s) (eg e9ccca5db27696ed8faa4427ec4110ddf230d141)\nr58454 = 96d6087a494bb7da6d90f02e8bd36833eaad2067 (refs/remotes/origin/R-2-14-branch)\n\tM\tdoc/manual/R-exts.texi\n\tM\tdoc/NEWS.Rd\n\tM\tsrc/library/tools/R/check.R\nr58455 = 742cbc791fa6760d5dfb4c4ea1e032d32e9e87c9 (refs/remotes/origin/trunk)\n----------------------------------8<-----------------------------------\n\n[1] - fbecd99 Update draft release notes to 2.2\n"},{"id":"251202","messageId":"20141030002801.GB31920@dcvr.yhbt.net","threadId":"37824","inReplyTo":"1414627570.41692.YahooMailBasic@web172306.mail.ir2.yahoo.com","subject":"Re: Regression and failure to clone/fetch with new code Re: git-svn performance","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2014-10-30T00:28:01Z","receivedAt":"2014-10-30T00:28:01Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Hin-Tak Leung wrote:\n> Argh, sorry. I thought I included the info but I didn't.\n\nThanks. I'll try a different version of svn later.\n\n> What do you think were missing in my e-mails?\n\nI was skimming and missed the part about Debian packages :)\n"},{"id":"251203","messageId":"1414630550.65737.YahooMailBasic@web172303.mail.ir2.yahoo.com","threadId":"37824","inReplyTo":"20141030002136.GA31920@dcvr.yhbt.net","subject":"Re: differences between old clone and new Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-30T00:55:50Z","receivedAt":"2014-10-30T00:55:50Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"--------------------------------------------\nOn Thu, 30/10/14, Eric Wong wrote:\n\n > The missing merge on branch\n \"R-2-14-branch\" is:\n > \n > commit\n 93af4d4cc3a5e0039944dd4e340d26995be8a252\n > Merge: 121990f 6ff1b87\n > Author: ripley \n > Date:   Wed Feb 22 13:45:34\n 2012 +0000\n > \n > \n    port r58453 from trunk\n >\n \n >     git-svn-id: https://svn.r-project.org/R/branches/R-2-14-branch@58454\n 00db46b3-68df-0310-9c12-caf00c1e9a41\n \n> I'm curious if you can tell me which\n version of git-svn you used to get\n that as a\n merge commit.  git-svn mergeinfo handling has changed\n (hopefully improved) over the years, so some\n differences in history\n can be\n (unfortunately) expected, I think.\n\nThat's quite straight-forward, I think - except for the recent burst (I am essentially\nadapting the git 2.1.0 release shipped by the upcoming fedora 21 scheduled for christmas)\nI tend to update to the latest fedora release about a week or two after release;\nfedora 17 was shipped in May 2012 and only just enter Alpha in 22 Feb 2012.\nand I tracked R at least as frequently as weekly around then;\nSo I would be using what ever version of git was shipping with fedora 16 around late\nFeb 2012.\n\nOn fedora's build farm, git-1.7.7.5 was bult in dec 2011 and git-1.7.7.6 was built\non 2012-01-19 . Depending on how soon\n1.7.7.6 filtered down to update, and when I update my git and also tracked R,\n(all three of these events probably happened around 22 Feb), I could be\nusing either 1.7.7.5 or 1.7.7.6. I still have the system software update log around\n(the repo was cloned on a now-dead system, then moved over when it died),\nand presumably I can get git log to show me the fetch date (?), I might\nbe able to tell whether it is 17.7.5 or 1.7.7.6 if you really want to know.\n"},{"id":"251204","messageId":"1414636504.45506.YahooMailBasic@web172304.mail.ir2.yahoo.com","threadId":"37824","inReplyTo":"20141030002801.GB31920@dcvr.yhbt.net","subject":"Re: Regression and failure to clone/fetch with new code Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-30T02:35:04Z","receivedAt":"2014-10-30T02:35:04Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"Here is the data dumper info . I tried the dumper code on the R repo\nas well, and saw that against the virtual box repo, there is one \ncurious difference - $self->{last_rev} is a string rather than a number.\nI tried hacking around doing \"$x += 0;\" to coerce last_rev\nto a number at various places but didn't get very far. There seems to be some caching\ncode in RA->get_dir so presumably that's why the same code run\non one repo gives it as string while on another gives it a number. Hope\nyou can figure where the coersion to string happened.\n\n--------\n$ git svn fetch --all\nIndex mismatch: d6c75bc195b1daad647322e2cc025bd31265c6b9 != 3927d05f6ab037fcf2b4d964c9633efade037d1b\nrereading a65b5fc0077c2fa80a344833b65ac19ff4ae88b6\n\tM\tsrc/VBox/Main/HostImpl.cpp\n$VAR1 = [\n bless( {\n 'map_root' => '.git/svn/refs/remotes/origin/trunk/.rev_map',\n '-use_svm_props' => undef,\n 'ra_uuid' => 'cfe28804-0f27-0410-a406-dd0f0b0b656f',\n 'pushurl' => undef,\n '-follow_parent' => 1,\n '-no_metadata' => undef,\n '-rewrite_uuid' => undef,\n 'repo_id' => 'svn',\n '-rewrite_root' => undef,\n 'index' => '.git/svn/refs/remotes/origin/trunk/index',\n 'dir' => '.git/svn/refs/remotes/origin/trunk',\n 'ref_id' => 'refs/remotes/origin/trunk',\n 'url' => 'http://www.virtualbox.org/svn/vbox',\n 'last_rev' => '28923',\n 'last_commit' => 'a65b5fc0077c2fa80a344833b65ac19ff4ae88b6',\n '_path' => 'trunk',\n 'config' => '.git/svn/config',\n 'logged_rev_props' => {\n 'log' => 'Main/Host: fix lock order issues in several methods\n',\n 'date' => '2010-04-30T09:08:17.252108Z',\n 'author' => 'vboxsync'\n }\n }, 'Git::SVN' ),\n 'trunk',\n '28923',\n 'trunk',\n 28924,\n '/branches/VBox-3.0:58652'\n ];\nIncorrect parameters given: Could not convert '%ld' into a number at /usr/share/perl5/vendor_perl/Git/SVN.pm line 1713.\n\n------\n\n--------------------------------------------\nOn Thu, 30/10/14, Eric Wong wrote:\n \n> I was skimming and missed the part about Debian\n packages :)\n\n\nI only asked because you mentioned using Debian :-).\nThe other 'Eric Wong' maintains/maintained a few chinese-related\ndebian packages, from some years ago.\n\nI know of two \"Ken Sharp\", one of ghostscript and another of wine,\nand two \"David Turner\", one of freetype and another of FSF's legal matters.\n"},{"id":"251209","messageId":"20141030084619.GA12697@dcvr.yhbt.net","threadId":"37824","inReplyTo":"1414636504.45506.YahooMailBasic@web172304.mail.ir2.yahoo.com","subject":"Re: Regression and failure to clone/fetch with new code Re: git-svn performance","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2014-10-30T08:46:19Z","receivedAt":"2014-10-30T08:46:19Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Hin-Tak Leung wrote:\n> Here is the data dumper info . I tried the dumper code on the R repo\n> as well, and saw that against the virtual box repo, there is one \n> curious difference - $self->{last_rev} is a string rather than a number.\n> I tried hacking around doing \"$x += 0;\" to coerce last_rev\n> to a number at various places but didn't get very far. There seems to be some caching\n> code in RA->get_dir so presumably that's why the same code run\n> on one repo gives it as string while on another gives it a number. Hope\n> you can figure where the coersion to string happened.\n\nThanks, I'm not able to reproduce the issue, but can you try the\nfollowing?\n\ndiff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm\nindex 75cdac9..82d6108 100644\n--- a/perl/Git/SVN/Ra.pm\n+++ b/perl/Git/SVN/Ra.pm\n@@ -153,6 +153,7 @@ sub url {\n sub check_path {\n \tmy ($self, $path, $r) = @_;\n \tmy $cache = $self->{cache}->{check_path};\n+\t$r = int($r);\n \tif ($r == $cache->{r} && exists $cache->{data}->{$path}) {\n \t\treturn $cache->{data}->{$path};\n \t}\n@@ -169,6 +170,7 @@ sub check_path {\n sub get_dir {\n \tmy ($self, $dir, $r) = @_;\n \tmy $cache = $self->{cache}->{get_dir};\n+\t$r = int($r);\n \tif ($r == $cache->{r}) {\n \t\tif (my $x = $cache->{data}->{$dir}) {\n \t\t\treturn wantarray ? @$x : $x->[0];\n---\nThe above should apply to my current master which has some\nminor cleanups (which I hope to send to Junio tomorrow).\n\nThe following changes since commit fbecd99861ea5795aeba46faf2ac7a8c1b70d485:\n\n Update draft release notes to 2.2 (2014-10-24 15:02:17 -0700)\n\nare available in the git repository at:\n\n git://bogomips.org/git-svn.git master\n\nfor you to fetch changes up to da0bc948ac2e01652a150fd4a57cebad6143242c:\n\n git-svn: add space after \"W:\" prefix in warning (2014-10-30 08:31:28 +0000)\n\n----------------------------------------------------------------\nEric Wong (11):\n git-svn: reduce check_cherry_pick cache overhead\n git-svn: cache only mergeinfo revisions\n git-svn: remove mergeinfo rev caching\n git-svn: reload RA every log-window-size\n git-svn: remove unnecessary DESTROY override\n git-svn: save a little memory as fetch progresses\n git-svn: disable _rev_list memoization\n Git.pm: add specified name to tempfile template\n git-svn: prepare SVN::Ra config pieces once\n git-svn: (cleanup) remove editor param passing\n git-svn: add space after \"W:\" prefix in warning\n\nJakob Stoklund Olesen (2):\n git-svn: only look at the new parts of svn:mergeinfo\n git-svn: only look at the root path for svn:mergeinfo\n\nSveinung Kvilhaugsvik (1):\n git-svn.txt: advertise pushurl with dcommit\n\n Documentation/git-svn.txt | 4 ++\n perl/Git.pm | 5 +-\n perl/Git/SVN.pm | 125 ++++++++++++++++++++++++++++------------------\n perl/Git/SVN/Ra.pm | 90 ++++++++++++++++++---------------\n 4 files changed, 134 insertions(+), 90 deletions(-)\n"},{"id":"251252","messageId":"20141030230831.GA14160@dcvr.yhbt.net","threadId":"37824","inReplyTo":"1414630550.65737.YahooMailBasic@web172303.mail.ir2.yahoo.com","subject":"Re: differences between old clone and new Re: git-svn performance","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2014-10-30T23:08:31Z","receivedAt":"2014-10-30T23:08:31Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Hin-Tak Leung wrote:\n> That's quite straight-forward, I think - except for the recent burst (I am essentially\n> adapting the git 2.1.0 release shipped by the upcoming fedora 21 scheduled for christmas)\n> I tend to update to the latest fedora release about a week or two after release;\n> fedora 17 was shipped in May 2012 and only just enter Alpha in 22 Feb 2012.\n> and I tracked R at least as frequently as weekly around then;\n> So I would be using what ever version of git was shipping with fedora 16 around late\n> Feb 2012.\n> \n> On fedora's build farm, git-1.7.7.5 was bult in dec 2011 and git-1.7.7.6 was built\n> on 2012-01-19 . Depending on how soon\n> 1.7.7.6 filtered down to update, and when I update my git and also tracked R,\n> (all three of these events probably happened around 22 Feb), I could be\n> using either 1.7.7.5 or 1.7.7.6. I still have the system software update log around\n> (the repo was cloned on a now-dead system, then moved over when it died),\n> and presumably I can get git log to show me the fetch date (?), I might\n> be able to tell whether it is 17.7.5 or 1.7.7.6 if you really want to know.\n\nI tried a full clone on 1.7.7.6 (no git-svn difference from 1.7.7.5).\nEven with that old git, I was able to reproduce the same merge behavior\nas current (Junio's) master as well as our recent patches.\n\nSo I believe r58454, r46925, and r46906 in the R repo are all handled\ncorrectly and no mergeinfo-handling regressions are introduced in the\nlatest round of git-svn changes. Thanks.\n"}]}