Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
On Sat, 1/11/14, Eric Wong normalper...@yhbt.net wrote: Hin-Tak Leung ht...@users.sourceforge.net 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. -- 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
[PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
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.yahoomailba...@web172304.mail.ir2.yahoo.com
ref: 1414722617.89476.yahoomailba...@web172305.mail.ir2.yahoo.com
Signed-off-by: Eric Wong normalper...@yhbt.net
Cc: Hin-Tak Leung ht...@users.sourceforge.net
---
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
--
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
Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
Eric Wong normalper...@yhbt.net 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 Filed a bug in Debian since I hit it in sid, too: http://bugs.debian.org/767530 Thanks all. -- 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
Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
-- On Fri, Oct 31, 2014 19:08 GMT Eric Wong wrote: Eric Wong normalper...@yhbt.net 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 Filed a bug in Debian since I hit it in sid, too: http://bugs.debian.org/767530 Thanks all. Hmm, but why are you filing at debian? I had the error when i applied the dev code patches on top of 2.1.0, and the error disappeared as soon as I reverted the patches. So it looks like a issue for the upstream developers, rather than distro. Are you saying debian is shipping a dev snapshot of git svn? -- 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
Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
Hin-Tak Leung ht...@users.sourceforge.net wrote: On Fri, Oct 31, 2014 19:08 GMT Eric Wong wrote: Filed a bug in Debian since I hit it in sid, too: http://bugs.debian.org/767530 Thanks all. Hmm, but why are you filing at debian? I had the error when i applied the dev code patches on top of 2.1.0, and the error disappeared as soon as I reverted the patches. So it looks like a issue for the upstream developers, rather than distro. Are you saying debian is shipping a dev snapshot of git svn? I don't track SVN upstream development, so haven't checked if it affects newer SVN, yet. It is the distro maintainer's job to get this resolved. This bug affects existing cases of git svn show-ignore, we just happened to find it with git svn fetch, first. Debian's bug tracker also has the lowest barrier to entry: no login/registration is necessary (just like this git list). If you want to handle this with upstream directly, please do. I try to avoid logins/accounts as much as possible. -- 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
Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
-
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.yahoomailba...@web172304.mail.ir2.yahoo.com
ref: 1414722617.89476.yahoomailba...@web172305.mail.ir2.yahoo.com
Signed-off-by: Eric Wong normalper...@yhbt.net
Cc: Hin-Tak Leung ht...@users.sourceforge.net
Tested-by: Hin-Tak Leung ht...@users.sourceforge.net
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
--
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
Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
Hin-Tak Leung ht...@users.sourceforge.net wrote: Tested-by: Hin-Tak Leung ht...@users.sourceforge.net 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@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. -- 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
Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
On Sat, 1/11/14, Eric Wong normalper...@yhbt.net wrote: Hin-Tak Leung ht...@users.sourceforge.net wrote: Tested-by: Hin-Tak Leung ht...@users.sourceforge.net 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@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) -- 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
Re: [PATCH v2] git-svn: use SVN::Ra::get_dir2 when possible
Hin-Tak Leung ht...@users.sourceforge.net 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... -- 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
