git svn fetch spewing warnings

Hi,

I'm using git 1.5.1.rc1.13.g0872 and I just tried the following to create a new git-svn tracked repository.

I did:

git svn init $URL
git svn fetch
# I also tried git svn fetch --no-follow-parent

The command eventually completed and left me with a working repository, but in the process I had screenfuls of warning messages like this:

W: Ignoring error from SVN, path probably does not exist: (175002): RA layer request failed: REPORT request failed on '/bioconductor/!svn/bc/12000': REPORT of '/bioconductor/!svn/bc/12000': Could not read chunk size: Secure connection truncated (https://hedgehog.fhcrc.org)
W: Ignoring error from SVN, path probably does not exist: (175002): RA layer request failed: REPORT request failed on '/bioconductor/!svn/bc/12100': REPORT of '/bioconductor/!svn/bc/12100': Could not read chunk size: Secure connection truncated (https://hedgehog.fhcrc.org)
W: Ignoring error from SVN, path probably does not exist: (175002): RA layer request failed: REPORT request failed on '/bioconductor/!svn/bc/12200': REPORT of '/bioconductor/!svn/bc/12200': Could not read chunk size: Secure connection truncated (https://hedgehog.fhcrc.org)

I haven't seen them before, but...

1. I haven't initialized a new repository in this way for awhile and git-svn has been updated

2. The subversion server I'm talking to was recently upgraded to

     1.4.2

Thanks,

+ seth

Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org

We now try harder to find previous versions of the path we're tracking. I've also changed the window from 1000 to 100 revisions, so the warning message spewing is 10 times more frequent. Don't worry, though it's harmless :)

Eric Wong

Not a big deal. But perhaps those warnings could go to a log file of some kind and then a summary at the end could say:

There were 500 warning messages, check git-svn-fetch-TIMESTAMP.log for details.

And to push a bit further, why do I care about these messages. What action might I take based on them? I almost didn't discover that the warnings were harmless because I C-c'd out a few times thinking that something was really wrong before deciding to just let it run.

+ seth

Seth Falcon

We ignore errors if the path we're tracking did not exist for a particular revision range, but we still print out warnings telling the user about that.

As pointed out by Seth Falcon, this amounts to a lot of warnings that could confuse and worry users. I'm not entirely comfortable completely silencing the warnings, but showing one warning per path that we track should be reasonable.

---
 git-svn.perl |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

index adc976c..d307d43 100755
@@ -2843,8 +2843,7 @@ package Git::SVN::Ra;
 use vars qw/@ISA $config_dir $_log_window_size/;
 use strict;
 use warnings;
-my ($can_do_switch);
-my $RA;
+my ($can_do_switch, %ignored_err, $RA);
 
 BEGIN {
 	# enforce temporary pool usage for some simple functions

@@ -3216,9 +3215,16 @@ sub skip_unknown_revs {
 	# 175007 - http(s):// (this repo required authorization, too...)
 	#   More codes may be discovered later...
 	if ($errno == 175007 || $errno == 175002 || $errno == 160013) {
-		warn "W: Ignoring error from SVN, path probably ",
-		     "does not exist: ($errno): ",
-		     $err->expanded_message,"\n";
+		my $err_key = $err->expanded_message;
+		# revision numbers change every time, filter them out
+		$err_key =~ s/\d+/\0/g;
+		$err_key = "$errno\0$err_key";
+		unless ($ignored_err{$err_key}) {
+			warn "W: Ignoring error from SVN, path probably ",
+			     "does not exist: ($errno): ",
+			     $err->expanded_message,"\n";
+			$ignored_err{$err_key} = 1;
+		}
 		return;
 	}
 	die "Error from SVN, ($errno): ", $err->expanded_message,"\n";

Eric Wong

Hi Eric,

Thanks, this is much quieter.

I have the impression that the initial fetch phase is taking longer than it used to. This could easily be due to network and server load related issues, but I wonder if something in the parent following / path searching is different. The first git svn fetch seems to do nothing for a very long time (except emit a few of the warnings) and then once it starts actually adding commits it goes quite fast. This isn't really a problem as the initial fetch is a fairly rare operation, but I wondered if this made sense based on recent git-svn changes...

+ seth

Does using --log-window-size=1000 speed things back up?

I decreased it to 100 to reduce memory usage (but exposed it as an option).

Eric Wong