* Eric Wong:
finish_report does seem to return a useful value indicating success
or failure, so we'll just set a flag when close_edit is called
(it is not called on failures, nor is abort_edit) and check
the flag before proceeding.
It seems that this needs some kind of fine-tuning. Now that git-svn
uses HTTP keepalive connections, you get a HTTP request error once you
run into the server-side request limit. It seems a bit excessive to
Florian Weimer [off-list ref] wrote:
* Eric Wong:
quoted
finish_report does seem to return a useful value indicating success
or failure, so we'll just set a flag when close_edit is called
(it is not called on failures, nor is abort_edit) and check
the flag before proceeding.
It seems that this needs some kind of fine-tuning. Now that git-svn
uses HTTP keepalive connections, you get a HTTP request error once you
run into the server-side request limit. It seems a bit excessive to
stop completely in this case.
Does the following patch help?
From: Eric Wong <redacted>
Date: Mon, 4 Dec 2006 00:51:16 -0800
Subject: [PATCH] git-svn: avoid network timeouts for long-running fetches
Long-running fetches run inside children to avoid memory leaks.
When we refork, the connection in the parent can be idle for a
long time; attempting to reuse it in the next child can result
in timeouts.
Signed-off-by: Eric Wong <redacted>
---
git-svn.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d0bd0bd..747daf0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -459,6 +459,7 @@ sub fetch_lib {
$min = $max + 1;
$max += $inc;
$max = $head if ($max > $head);
+ $SVN = libsvn_connect($SVN_URL);
}
restore_index($index);
return { revision => $last_rev, commit => $last_commit };--