All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Roman Kagan <rkagan@mail.ru>
Cc: Eric Wong <normalperson@yhbt.net>,
	Jonathan Nieder <jrnieder@gmail.com>,
	git@vger.kernel.org, Benjamin Pabst <benjamin.pabst85@gmail.com>
Subject: Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
Date: Fri, 17 Jan 2014 11:23:15 -0800	[thread overview]
Message-ID: <xmqqr486wgyk.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CANiYKX4VhxZsuwKMfaMToner-+ipYmsFy_T6Bgxwj_a950PA3A@mail.gmail.com> (Roman Kagan's message of "Fri, 17 Jan 2014 15:32:01 +0400")

Roman Kagan <rkagan@mail.ru> writes:

> 2013/12/31 Roman Kagan <rkagan@mail.ru>:
>> 2013/12/30 Junio C Hamano <gitster@pobox.com>:
>>> Roman Kagan <rkagan@mail.ru> writes:
>>>> I'd like to note that it's IMO worth including in the 'maint' branch
>>>> as it's a crasher.  Especially so since the real fix has been merged
>>>> in the subversion upstream and nominated for 1.8 branch, so the
>>>> workaround may soon lose its relevance.
>>>
>>> I do not quite get this part, though.
>>>
>>> If they refused to fix it for real, it would make it likely that
>>> this workaround will stay relevant for a long time, in which case it
>>> would be worth cherry-picking to an older maintenance track.  But if
>>> this workaround is expected to lose its relevance shortly, I see it
>>> as one less reason to cherry-pick it to an older maintenance track.
>>>
>>> Confused...
>>
>> I thought it was exactly the other way around.  By the time the next
>> feature release reaches users, chances are they'd already have
>> subversion with the fix.  OTOH the workaround would benefit those who
>> get their maintenance release of git (e.g. through their Linux distro
>> update) before they get their maintenance release of subversion.
>
> So this actually happened: 1.8.5.3 is out, and some distributions are
> shipping it (Arch, Debian), but the workaround didn't make it there.

The way I read your message was that the fix on the subversion side
is already there and this patch to work it around on our end is of
no importance.

But actually you wanted to say quite the opposite.  They are slow
and it is likely that we need to work their bug around for a while.

If so, then I think it might make sense to cherry-pick it to the
maint branch, even though we usually apply only fixes to our own
bugs to the maintenance track.

  reply	other threads:[~2014-01-17 19:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAM-uYMgy8duxdGY8rbCJv9To3FFMAUDv22nnzbQ+e3QrTCLLpQ@mail.gmail.com>
     [not found] ` <CAM-uYMigCTK=j3HkyT0F=jtDoDERdtkpZiTXRvBhSHJW3edJ-w@mail.gmail.com>
2013-11-14 15:26   ` Fwd: Error with git-svn pushing a rename Benjamin Pabst
2013-11-15  7:34     ` Andreas Stricker
     [not found]       ` <CAM-uYMgn4SGqurqRG-RDiicLxpf9NfTPUvNn9FaFUUbxFRJsZw@mail.gmail.com>
2013-11-15 13:36         ` Andreas Stricker
2013-11-15 22:53           ` Jonathan Nieder
2013-11-17 22:55             ` Andreas Stricker
2013-11-20 22:10               ` Benjamin Pabst
2013-12-24 21:11                 ` Roman Kagan
2013-12-25 10:52                   ` Roman Kagan
2013-12-25 13:13                     ` Roman Kagan
2013-12-25 16:31                   ` Thomas Rast
2013-12-26 12:05                     ` [PATCH] git-svn: workaround for a bug in svn serf backend Roman Kagan
2013-12-26 20:28                       ` Jonathan Nieder
2013-12-27  6:09                         ` Roman Kagan
2013-12-27  7:52                           ` Roman Kagan
2013-12-27  8:05                         ` [PATCH v2] " Roman Kagan
2013-12-27 20:07                           ` Jonathan Nieder
2013-12-27 20:34                             ` Eric Wong
2013-12-27 22:22                               ` Junio C Hamano
2013-12-28  9:58                                 ` Roman Kagan
2013-12-30 19:44                                   ` Junio C Hamano
2013-12-31  7:20                                     ` Roman Kagan
2014-01-17 11:32                                       ` Roman Kagan
2014-01-17 19:23                                         ` Junio C Hamano [this message]
2014-01-06 15:51                                   ` Andreas Stricker
2013-12-30 12:20                       ` [PATCH] " Thomas Rast
2013-12-30 16:01                         ` Roman Kagan
2013-11-18 17:59           ` Fwd: Error with git-svn pushing a rename Benjamin Pabst

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=xmqqr486wgyk.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=benjamin.pabst85@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=normalperson@yhbt.net \
    --cc=rkagan@mail.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.