Roman Kagan <rka...@mail.ru> writes:
> 2013/12/31 Roman Kagan <rka...@mail.ru>:
>> 2013/12/30 Junio C Hamano <gits...@pobox.com>:
>>> Roman Kagan <rka...@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.
>> 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: 18.104.22.168 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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html