# Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible 5 messages from 2014-10-31 to 2014-11-01. Participants: Hin-Tak Leung, Eric Wong. Thread: https://gitlist.dev/t/37863 ## Hin-Tak Leung, 2014-10-31 21:53 Subject: Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible Message-ID: <1414792434.54806.YahooMailBasic@web172304.mail.ir2.yahoo.com> URL: https://gitlist.dev/e/1414792434.54806.YahooMailBasic%40web172304.mail.ir2.yahoo.com ``` ------------------------- On Fri, Oct 31, 2014 10:34 GMT Eric Wong wrote: >This avoids the following failure with normal "get_dir" on newer >versions of SVN (tested with SVN 1.8.8-1ubuntu3.1): > >  Incorrect parameters given: Could not convert '%ld' into a number > >get_dir2 also has the potential to be more efficient by requesting >less data. > >ref: <1414636504.45506.YahooMailBasic@web172304.mail.ir2.yahoo.com> >ref: <1414722617.89476.YahooMailBasic@web172305.mail.ir2.yahoo.com> > >Signed-off-by: Eric Wong >Cc: Hin-Tak Leung Tested-by: Hin-Tak Leung Okay, this one on top of my "git 2.1.0 + 10 recent git svn improvement patches" allow me to fetch further. I suspect the problem must be elsewhere though, and this just band-aided over it. For me, reverting the additional patches and just use git 2.1.0 also allow me to fetch further, so the problem appear to me to be associated with the additional patches. But you are saying that git-svn on debian as shipped exhibit this problem? >--- > Sorry, waaay past my bed time.  This version doesn't infinite loop > on autoload or older SVN(*) (at least I hope it doesn't) > > perl/Git/SVN/Ra.pm | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > >diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm >index 82d6108..496f430 100644 >--- a/perl/Git/SVN/Ra.pm >+++ b/perl/Git/SVN/Ra.pm >@@ -177,7 +177,17 @@ sub get_dir { >         } >     } >     my $pool = SVN::Pool->new; >-    my ($d, undef, $props) = $self->SUPER::get_dir($dir, $r, $pool); >+    my ($d, undef, $props); >+ >+    if (::compare_svn_version('1.4.0') >= 0) { >+        # n.b. in addition to being potentially more efficient, >+        # this works around what appears to be a bug in some >+        # SVN 1.8 versions >+        my $kind = 1; # SVN_DIRENT_KIND >+        ($d, undef, $props) = $self->get_dir2($dir, $r, $kind, $pool); >+    } else { >+        ($d, undef, $props) = $self->SUPER::get_dir($dir, $r, $pool); >+    } >     my %dirents = map { $_ => { kind => $d->{$_}->kind } } keys %$d; >     $pool->clear; >     if ($r != $cache->{r}) { >-- >EW > ``` ## Eric Wong, 2014-10-31 23:22 Subject: Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible Message-ID: <20141031232222.GA30046@dcvr.yhbt.net> URL: https://gitlist.dev/e/20141031232222.GA30046%40dcvr.yhbt.net In-Reply-To: <1414792434.54806.YahooMailBasic@web172304.mail.ir2.yahoo.com> ``` Hin-Tak Leung wrote: > Tested-by: Hin-Tak Leung > > Okay, this one on top of my "git 2.1.0 + 10 recent git svn improvement patches" > allow me to fetch further. > > I suspect the problem must be elsewhere though, and this just band-aided > over it. > > For me, reverting the additional patches and just use git 2.1.0 also allow > me to fetch further, so the problem appear to me to be associated with > the additional patches. Junio already pulled all of those git-svn patches into git 2.2.0-rc0: http://mid.gmane.org/xmqq7fzgt0q4.fsf@gitster.dls.corp.google.com Can you give that a try? I've been able to complete the vbox fetch without problems. > But you are saying that git-svn on debian as shipped > exhibit this problem? No, I'm saying unrelated, (old) functionality such as "git svn show-ignore" also got broken by this SVN bug. ``` ## Hin-Tak Leung, 2014-11-01 02:19 Subject: Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible Message-ID: <1414808346.73568.YahooMailBasic@web172303.mail.ir2.yahoo.com> URL: https://gitlist.dev/e/1414808346.73568.YahooMailBasic%40web172303.mail.ir2.yahoo.com In-Reply-To: <20141031232222.GA30046@dcvr.yhbt.net> ``` -------------------------------------------- On Sat, 1/11/14, Eric Wong wrote: Hin-Tak Leung wrote: > > Tested-by: Hin-Tak Leung > > Okay, this one on top of my "git 2.1.0 + 10 recent git svn improvement patches" > allow me to fetch further. > > I suspect the problem must be elsewhere though, and this just band-aided > over it. > > For me, reverting the additional patches and just use git 2.1.0 also allow > me to fetch further, so the problem appear to me to be associated with > the additional patches. > Junio already pulled all of those git-svn patches into git 2.2.0-rc0: > http://mid.gmane.org/xmqq7fzgt0q4.fsf@gitster.dls.corp.google.com > Can you give that a try?  I've been able to complete the vbox fetch without problems. While my 2.10 + 11 patches continue to fetch, where it was stuck, now it does "Couldn't find revmap..." - also, the single branch clone is doing the 'trunk/branches/... thing - are these supposed to happen? --stdlayout: $ git svn fetch --all Index mismatch: d6c75bc195b1daad647322e2cc025bd31265c6b9 != 3927d05f6ab037fcf2b4d964c9633efade037d1b rereading a65b5fc0077c2fa80a344833b65ac19ff4ae88b6 M src/VBox/Main/HostImpl.cpp Checking svn:mergeinfo changes since r28923: 1 sources, 1 changed Couldn't find revmap for http://www.virtualbox.org/svn/vbox/branches/VBox-3.0 r28924 = 4e01065451e00c725c88113584461ee3284e3952 (refs/remotes/origin/trunk) without --stdlayout: $ git svn fetch --all Index mismatch: d6c75bc195b1daad647322e2cc025bd31265c6b9 != 3927d05f6ab037fcf2b4d964c9633efade037d1b rereading a65b5fc0077c2fa80a344833b65ac19ff4ae88b6 M src/VBox/Main/HostImpl.cpp Checking svn:mergeinfo changes since r28923: 1 sources, 1 changed Couldn't find revmap for http://www.virtualbox.org/svn/vbox/trunk/branches/VBox-3.0 r28924 = 4e01065451e00c725c88113584461ee3284e3952 (refs/remotes/git-svn) ``` ## Eric Wong, 2014-11-01 03:13 Subject: Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible Message-ID: <20141101031352.GA17306@dcvr.yhbt.net> URL: https://gitlist.dev/e/20141101031352.GA17306%40dcvr.yhbt.net In-Reply-To: <1414808346.73568.YahooMailBasic@web172303.mail.ir2.yahoo.com> ``` Hin-Tak Leung wrote: > While my 2.10 + 11 patches continue to fetch, where it was stuck, now > it does "Couldn't find revmap..." - also, the single branch clone is doing > the 'trunk/branches/... thing - are these supposed to happen? I'm afraid this is a problem with the vbox repo not publishing anything but trunk, but their svn:mergeinfo refers to non-public branches. This shows only changes to trunk: svn log -v http://www.virtualbox.org/svn/vbox I do not know what their development process is like. From the looks of it, every change is made by a "vboxsync" user. I suspect that's driven by an automated export script, and the real development happens in a different (private) repo... ``` ## Hin-Tak Leung, 2014-11-01 06:13 Subject: Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible Message-ID: <1414822394.95382.YahooMailBasic@web172305.mail.ir2.yahoo.com> URL: https://gitlist.dev/e/1414822394.95382.YahooMailBasic%40web172305.mail.ir2.yahoo.com In-Reply-To: <20141101031352.GA17306@dcvr.yhbt.net> ``` -------------------------------------------- On Sat, 1/11/14, Eric Wong wrote: Hin-Tak Leung wrote: > > While my 2.10 + 11 patches continue to fetch, where it was stuck, now > it does "Couldn't find revmap..." - also, the single branch clone is doing > the 'trunk/branches/... thing - are these supposed to happen? > I'm afraid this is a problem with the vbox repo not publishing anything but trunk, but their svn:mergeinfo refers to non-public branches. > This shows only changes to trunk: >     svn log -v http://www.virtualbox.org/svn/vbox > I do not know what their development process is like.  From the looks of it, every change is made by a "vboxsync" user.  I suspect that's driven by an automated export script, and the real development happens in a different (private) repo... They are Sun/Oracle technology so have that sort of style, I think. (Think Java and everything to do with Java). I did get a bit confused about that - their web code broswing interface shows a number of merges and deleted branches. ```