On Tue, Jan 25, 2011 at 1:23 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote: > On Tue, Jan 25, 2011 at 1:14 PM, Stefan Sperling <s...@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.
Created issue 3789 and set target milestone 1.7.0. http://subversion.tigris.org/issues/show_bug.cgi?id=3789 Kevin R.
