Argh, sorry. I thought I included the info but I didn't. git 2.1.0 + 10 patches aborts after trunk@28923 (i.e. failing to fetch 28924); if I revert the patches in that order (#5,#4,#2, #1) and retry in the middle, I have to revert all 4 to get 'git svn fetch' to continue on to 28924. I tried --stdlayout (it seems that there were branches, but just merged and "deleted" according to the web code browsing interface) but it failed at the same revision. I'll try the data dump and see what it gives me... What do you think were missing in my e-mails? The differences of new clone against old is a missing merge in at R-2-14-branch@58454 , and two extra merges at djm-parseRd@46925 and djm-parseRd@46906 . -------------------------------------------- On Wed, 29/10/14, Eric Wong <normalperson@xxxxxxxx> wrote: Subject: Re: Regression and failure to clone/fetch with new code Re: git-svn performance To: "Hin-Tak Leung" <htl10@xxxxxxxxxxxxxxxxxxxxx> Cc: stoklund@xxxxxx, fabian.schmied@xxxxxxxxx, git@xxxxxxxxxxxxxxx, sam@xxxxxxxxxx, stevenrwalter@xxxxxxxxx, waste.manager@xxxxxx, amyrick@xxxxxxxxx Date: Wednesday, 29 October, 2014, 20:23 Hin-Tak Leung <htl10@xxxxxxxxxxxxxxxxxxxxx> wrote: > Hi, I patched my system git with the recent git-svn improvements, and just use > it for general use; so theses are the patches, against 2.1.0. > > 0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch > 0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patch > 0003-git-svn-reduce-check_cherry_pick-cache-overhead.patch > 0004-git-svn-cache-only-mergeinfo-revisions.patch > 0005-git-svn-remove-mergeinfo-rev-caching.patch > 0006-git-svn.txt-advertise-pushurl-with-dcommit.patch > 0007-git-svn-reload-RA-every-log-window-size.patch > 0008-git-svn-remove-unnecessary-DESTROY-override.patch > 0009-git-svn-save-a-little-memory-as-fetch-progresses.patch > 0010-git-svn-disable-_rev_list-memoization.patch > > trying to do this: > git svn clone http://www.virtualbox.org/svn/vbox/trunk vbox > > (there is no publicly visible branches, so it is just a straight-forward single-branch clone). > > aborts with > > --------------- > M src/VBox/Main/HostImpl.cpp > Incorrect parameters given: Could not convert '%ld' into a number at /usr/share/perl5/vendor_perl/Git/SVN.pm line 1711. > > $ git svn fetch --all > Index mismatch: d6c75bc195b1daad647322e2cc025bd31265c6b9 != 3927d05f6ab037fcf2b4d964c9633efade037d1b > rereading a65b5fc0077c2fa80a344833b65ac19ff4ae88b6 > M src/VBox/Main/HostImpl.cpp > Incorrect parameters given: Could not convert '%ld' into a number at /usr/share/perl5/vendor_perl/Git/SVN.pm line 1711. > ---------------- > > I have never seen such behavior before, and seeing as the lines indicated are in > a routine called "mergeinfo_changes", and recently added/changed by > quite a few of the patches, I started reverting from the back in this order: #5, #4, #2, #1 > and tried again between each revert. And it finally allows me to fetch again after > reverting #1. Me neither, this is new bug to me. I cannot reproduce it, either. Which revision did you hit this on? I completed your vbox trunk clone without any problems on my side (Debian i386, SVN 1.6.17). Can you try the following to dump out the parameters passed to mergeinfo_changes? --- a/perl/Git/SVN.pm +++ b/perl/Git/SVN.pm @@ -1695,8 +1695,10 @@ sub parents_exclude { } # Compute what's new in svn:mergeinfo. +use Data::Dumper; sub mergeinfo_changes { my ($self, $old_path, $old_rev, $path, $rev, $mergeinfo_prop) = @_; + print STDERR Dumper(\@_); my %minfo = map {split ":", $_ } split "\n", $mergeinfo_prop; my $old_minfo = {}; Btw, I missed part of your other email, but no, I never maintained any Chinese packages in Debian. > I don't see any %ld close by, but presumably this is enough information for somebody else > to try. The platform is linux x86_64. (mostly fedora 20 but with a lot of additional > changes like a newer gnome than shipped, etc so probably not really fc20) > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html