Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
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. Could you please consider including it in 'maint', so that 1.8.5.4 brings them a working combination of git and subversion? Roman. -- 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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
Hi Roman git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +) Thanks! Well thanks to you for finding and fixing this bug that really annoyed me just before Christmas again. Your bug analysis proved my observation that even a fresh checkout (as I suggested in my last message) didn't fix this issue. And thanks to the reviewers too. Awesome! ~Andy -- 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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
Roman Kagan rka...@mail.ru writes: 2013/12/28 Junio C Hamano gits...@pobox.com: Eric Wong normalper...@yhbt.net writes: git://git.bogomips.org/git-svn.git master for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace: git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +) Roman Kagan (1): git-svn: workaround for a bug in svn serf backend perl/Git/SVN/Editor.pm | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Thanks. I almost missed this pull-request, though. Will pull. Thanks! That's redundant; the project should thank you for contributing, not the other way around. 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... -- 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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
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. Documentation/SubmittingPatches also suggests to submit bugfixes against 'maint'. But I might have got it wrong... Roman. -- 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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
2013/12/28 Junio C Hamano gits...@pobox.com: Eric Wong normalper...@yhbt.net writes: git://git.bogomips.org/git-svn.git master for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace: git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +) Roman Kagan (1): git-svn: workaround for a bug in svn serf backend perl/Git/SVN/Editor.pm | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Thanks. I almost missed this pull-request, though. Will pull. Thanks! 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. Roman. -- 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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
Roman Kagan wrote: Subversion serf backend in versions 1.8.5 and below has a bug that the function creating the descriptor of a file change -- add_file() -- doesn't make a copy of its third argument when storing it on the returned descriptor. As a result, by the time this field is used (in transactions of file copying or renaming) it may well be released, and the memory reused. One of its possible manifestations is the svn assertion triggering on an invalid path, with a message svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed. [...] Makes sense. Perhaps also worth mentioning that this is fixed by r1553376, but no need to reroll just for that. Cc: Benjamin Pabst benjamin.pabs...@gmail.com Cc: Eric Wong normalper...@yhbt.net Cc: Jonathan Nieder jrnie...@gmail.com No need for these lines --- the mail header already keeps track of who is being cc-ed. Signed-off-by: Roman Kagan rka...@mail.ru Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks. -- 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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
Jonathan Nieder jrnie...@gmail.com wrote: Roman Kagan wrote: Subversion serf backend in versions 1.8.5 and below has a bug that the function creating the descriptor of a file change -- add_file() -- doesn't make a copy of its third argument when storing it on the returned descriptor. As a result, by the time this field is used (in transactions of file copying or renaming) it may well be released, and the memory reused. One of its possible manifestations is the svn assertion triggering on an invalid path, with a message svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed. [...] Makes sense. Perhaps also worth mentioning that this is fixed by r1553376, but no need to reroll just for that. Thanks all, I noted this in an addendum to the commit: Subversion serf backend in versions 1.8.5 and below has a bug(*) that the ... * [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder] Cc: Benjamin Pabst benjamin.pabs...@gmail.com Cc: Eric Wong normalper...@yhbt.net Cc: Jonathan Nieder jrnie...@gmail.com No need for these lines --- the mail header already keeps track of who is being cc-ed. I don't mind seeing it in history. At least I've gotten accustomed to it from the Linux kernel and tracking patch flow between dev - stable trees. Signed-off-by: Roman Kagan rka...@mail.ru Reviewed-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Eric Wong normalper...@yhbt.net The following changes since commit 7794a680e63a2a11b73cb1194653662f2769a792: Sync with 1.8.5.2 (2013-12-17 14:12:17 -0800) are available in the git repository at: git://git.bogomips.org/git-svn.git master for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace: git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +) Roman Kagan (1): git-svn: workaround for a bug in svn serf backend perl/Git/SVN/Editor.pm | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) -- 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
Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend
Eric Wong normalper...@yhbt.net writes: Jonathan Nieder jrnie...@gmail.com wrote: Roman Kagan wrote: Subversion serf backend in versions 1.8.5 and below has a bug that the function creating the descriptor of a file change -- add_file() -- doesn't make a copy of its third argument when storing it on the returned descriptor. As a result, by the time this field is used (in transactions of file copying or renaming) it may well be released, and the memory reused. One of its possible manifestations is the svn assertion triggering on an invalid path, with a message svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed. [...] Makes sense. Perhaps also worth mentioning that this is fixed by r1553376, but no need to reroll just for that. Thanks all, I noted this in an addendum to the commit: Subversion serf backend in versions 1.8.5 and below has a bug(*) that the ... * [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder] Cc: Benjamin Pabst benjamin.pabs...@gmail.com Cc: Eric Wong normalper...@yhbt.net Cc: Jonathan Nieder jrnie...@gmail.com No need for these lines --- the mail header already keeps track of who is being cc-ed. I don't mind seeing it in history. At least I've gotten accustomed to it from the Linux kernel and tracking patch flow between dev - stable trees. Signed-off-by: Roman Kagan rka...@mail.ru Reviewed-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Eric Wong normalper...@yhbt.net The following changes since commit 7794a680e63a2a11b73cb1194653662f2769a792: Sync with 1.8.5.2 (2013-12-17 14:12:17 -0800) are available in the git repository at: git://git.bogomips.org/git-svn.git master for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace: git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +) Roman Kagan (1): git-svn: workaround for a bug in svn serf backend perl/Git/SVN/Editor.pm | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Thanks. I almost missed this pull-request, though. Will pull. -- 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
