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. >>> >>> 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. -- 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
