git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uli Heller" <uli.heller@daemons-point.com>
To: "Kyle J. McKay" <mackyle@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Eric Wong" <normalperson@yhbt.net>
Subject: Re: [PATCH] git-svn: Fix termination issues for remote svn  connections
Date: Fri, 6 Sep 2013 14:06:32 +0200 (CEST)	[thread overview]
Message-ID: <07b9b270090d6b42515c5dc3dfb8ab4f.squirrel@83.236.132.106> (raw)
In-Reply-To: <A46AD76E-56FA-4555-8811-6141284300DD@gmail.com>

On Fri, September 6, 2013 1:46 pm, Kyle J. McKay wrote:
> On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
>> "Uli Heller" <uli.heller@daemons-point.com> writes:
>>
>>> When using git-svn in combination with serf-1.2.1 core dumps are
>>> created on termination. This is caused by a bug in serf, a fix for
>>> the bug exists (see
>>> https://code.google.com/p/serf/source/detail?r=2146)
>>> .
>>> Nevertheless, I think it makes sense to fix the issue within the
>>> git perl module Ra.pm, too. The change frees the private copy of
>>> the remote access object on termination which prevents the error
>>> from happening.
>>>
>>> Note: Since subversion-1.8.0 and later do require serf-1.2.1 or
>>> later,
>>> the core dumps typically do show up when upgrading to a recent
>>> version
>>> of subversion.
>>>
>>> Credits: Jonathan Lambrechts for proposing a fix to Ra.pm.
>>> Evgeny Kotkov and Ivan Zhakov for fixing the issue in serf and
>>> pointing me to that fix.
>>> ---
>>
>> Thanks.  Please sign-off your patch.
>>
>> I am Cc'ing Kyle McKay who apparently had some experience working
>> with git-svn with newer svn that can only use serf, hoping that we
>> can get an independent opinion/test just to be sure.  Also Cc'ed is
>> Eric Wong who has been the official git-svn area expert, but I
>> understand that Eric hasn't needed to use git-svn for quite a while,
>> so it is perfectly fine if he does not have any comment on this one.
>>
>> We may want to find a volunteer to move "git svn" forward as a new
>> area expert (aka subsystem maintainer), by the way.
>>
>>> perl/Git/SVN/Ra.pm | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
>>> index 75ecc42..78dd346 100644
>>> --- a/perl/Git/SVN/Ra.pm
>>> +++ b/perl/Git/SVN/Ra.pm
>>> @@ -32,6 +32,11 @@ BEGIN {
>>> 	}
>>> }
>>>
>>> +END {
>>> +	$RA = undef;
>>> +	$ra_invalid = 1;
>>> +}
>>> +
>>> sub _auth_providers () {
>>> 	my @rv = (
>>> 	  SVN::Client::get_simple_provider(),
>
> I have not, as of yet, been able to reproduce the problem, so I cannot
> verify the solution.  Maybe Uli can provide an example of a git-svn
> command that demonstrates the failure?
>
> I am running a fresh build of subversion 1.8.3 with serf version 1.3.1
> (the most recent serf release).
>
> According to the serf library history, version 1.3.1 of serf was
> tagged at revision 2139 from revision 2138, but the serf fix mentioned
> above was checked in at revision 2146, so it cannot possibly be in the
> serf 1.3.1 release.
>
> I'm using Git built from master (57e4c1783).  I see the same behavior
> both with and without the SVN/Ra.pm patch (and using both bulk updates
> and skelta mode).  Does the problem not happen on a git svn clone?  I
> can force serf back to version 1.2.1 and try that version just to see,
> but I would like to have an example of a known failing git svn command
> for testing purposes.  Thanks.

I think this command should produce the error:

  git svn clone --stdlayout https://github.com/uli-heller/uli-javawrapper

You can use any other svn repo as well, you only have to specify an HTTPS
url.

[Yes, I know you typically don't clone github via git svn]

I'll do some more tests using git HEAD and serf 1.3.1 when I'm back home.

Thanks + best regards, Uli

  reply	other threads:[~2013-09-06 12:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03  7:35 [PATCH] git-svn: Fix termination issues for remote svn connections Uli Heller
2013-09-05 18:48 ` Junio C Hamano
2013-09-05 19:02   ` Eric Wong
2013-09-05 23:14     ` Junio C Hamano
2013-09-06 11:46   ` Kyle J. McKay
2013-09-06 12:06     ` Uli Heller [this message]
2013-09-06 12:44       ` Kyle J. McKay
2013-09-06 13:18         ` Uli Heller
2013-09-06 16:41           ` Junio C Hamano
2013-09-09  6:01             ` [PATCH v2] " Uli Heller
2013-09-09 15:42               ` Junio C Hamano
2013-09-06 12:44   ` [PATCH] " Kyle J. McKay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=07b9b270090d6b42515c5dc3dfb8ab4f.squirrel@83.236.132.106 \
    --to=uli.heller@daemons-point.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mackyle@gmail.com \
    --cc=normalperson@yhbt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).