On Tue, Jan 25, 2011 at 1:14 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Jan 25, 2011 at 10:34:43AM -0600, Kevin Radke wrote:
>> (I'm moving this conversation from users to dev, since I have
>> convinced myself a regression was introduced in r1028108)
>> See: http://svn.haxx.se/users/archive-2010-12/0265.shtml
>>
>> log -v -g --xml http://server/repo/path commands will now fail for
>> "complex" histories that contain file renames.
>>
>> The client sees:
>> svn: REPORT of '/repo/!svn/bc/1234/path/in/repo': Could not read chunk
>> size: connection was closed by server (http://server)
>>
>> The server logs:
>> [Wed Dec 15 15:48:18 2010] [error] [client 192.168.1.1] File not
>> found: revision 5678, path '/path/in/repo/file.txt' [404, #160013]
>>
>> (The file was named oldfilename.txt in r5678, because it was renamed
>> in r7890. Something isn't using the correct name when more than
>> MAX_OPEN_HISTORIES have been found.)
>>
>> The only source file modified in this commit was subversion/libsvn_reops/log.c
>>
>> A few questions:
>>
>> 1) Does setting info->oldpool and info->newpool to NULL around lines
>> 1113 potentially leak memory?
>> 2) What is info->first_time used for? It seems to always be set to
>> true in the loop in get_path_histories() and then reset in
>> get_history()
>> 3) Increasing MAX_OPEN_HISTORIES to 128 "fixes" my test repository,
>> but isn't the true fix.
>
> Thanks for bringing this to dev@.
> If it's not too much of a bother, could you also file an issue for this
> and set the target milestone to 1.7.0 so we don't forget about it?
> This milestone doesn't mean that a fix for 1.6.x won't be made.
> It just exploits the fact that currently most people are looking at
> issues scheduled for 1.7.0 :)
I milestone 1.7.0 issue also means that it's a blocker for the 1.7.x
branch, iiuc.
-Hyrum
Received on 2011-01-25 20:24:28 CET