git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 17, 2014, 19:23 UTC
Message-ID
<xmqqr486wgyk.fsf@gitster.dls.corp.google.com>
In-Reply-To
<CANiYKX4VhxZsuwKMfaMToner-+ipYmsFy_T6Bgxwj_a950PA3A@mail.gmail.com>
Roman Kagan <rkagan@mail.ru> writes:
Show 26 quoted lines
> 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.

Previous: Roman KaganNext: Andreas Stricker
Message 23 of 27 in “Fwd: Error with git-svn pushing a rename”
  1. Benjamin PabstNov 14, 2013
  2. Andreas StrickerNov 15, 2013
  3. Andreas StrickerNov 15, 2013
  4. Jonathan NiederNov 15, 2013
  5. Andreas StrickerNov 17, 2013
  6. Benjamin PabstNov 20, 2013
  7. Roman KaganDec 24, 2013
  8. Roman KaganDec 25, 2013
  9. Roman KaganDec 25, 2013
  10. Thomas RastDec 25, 2013
  11. git-svn: workaround for a bug in svn serf backendRoman Kagan, Dec 26, 2013
  12. Jonathan NiederDec 26, 2013
  13. Roman KaganDec 27, 2013
  14. Roman KaganDec 27, 2013
  15. git-svn: workaround for a bug in svn serf backendRoman Kagan, Dec 27, 2013
  16. Jonathan NiederDec 27, 2013
  17. Eric WongDec 27, 2013
  18. Junio C HamanoDec 27, 2013
  19. Roman KaganDec 28, 2013
  20. Junio C HamanoDec 30, 2013
  21. Roman KaganDec 31, 2013
  22. Roman KaganJan 17, 2014
  23. Junio C HamanoJan 17, 2014
  24. Andreas StrickerJan 6, 2014
  25. Thomas RastDec 30, 2013
  26. Roman KaganDec 30, 2013
  27. Benjamin PabstNov 18, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.