Re: Regression and failure to clone/fetch with new code Re: git-svn performance

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@yhbt.net> wrote:

 Subject: Re: Regression and failure to clone/fetch with new code Re: git-svn performance
 To: "Hin-Tak Leung" <htl10@users.sourceforge.net>
 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
 Date: Wednesday, 29 October, 2014, 20:23
 
 Hin-Tak Leung <htl10@users.sourceforge.net>
 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) 
 >