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

2013-12-30 Thread Thomas Rast
Roman Kagan rka...@mail.ru writes: + # workaround for a bug in svn serf backend (v1.8.5 and below): + # store 3d argument to -add_file() in a local variable, to make it + # have the same lifetime as $fbat + my $upa = $self-url_path($m-{file_a}); my $fbat =

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

2013-12-30 Thread Roman Kagan
2013/12/30 Thomas Rast t...@thomasrast.ch: Roman Kagan rka...@mail.ru writes: + # workaround for a bug in svn serf backend (v1.8.5 and below): + # store 3d argument to -add_file() in a local variable, to make it + # have the same lifetime as $fbat + my $upa =

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

2013-12-26 Thread Roman Kagan
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 3d argument when storing it on the returned descriptor. As a result, by the time this field is used (in transactions of file copying

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

2013-12-26 Thread Jonathan Nieder
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 3d argument when storing it on the returned 3d makes me think of 3-dimensional. ;-) I think you mean third

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

2013-12-26 Thread Roman Kagan
2013/12/27 Jonathan Nieder jrnie...@gmail.com: 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 3d argument when storing it on the returned 3d makes me

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

2013-12-26 Thread Roman Kagan
2013/12/27 Roman Kagan rka...@mail.ru: 2013/12/27 Jonathan Nieder jrnie...@gmail.com: Could this be reproduced with a test script to make sure we don't reintroduce the bug again later? (It's okay if the test only fails on machines with the problematic svn version.) That would need a fairly