kmra...@rockwellcollins.com wrote on 01/20/2011 02:26:02 PM: > Stefan Sperling <s...@elego.de> wrote on 12/16/2010 03:11:03 PM: > > On Thu, Dec 16, 2010 at 02:50:27PM -0600, kmra...@rockwellcollins.com wrote: > > > I have observed some regressions with > > > > > > log -v -g --xml http://server/repo/path > > > > > > output in 1.6.15 that were not present in 1.6.13. I see a lot of -g
> > > changes > > > in this new version. > > > > Hi Kevin, > > > > There are three -g changes: > > > > * fix server-side memory leaks triggered by 'blame -g' (r1032808) > > * allow 'log -g' to continue in the face of invalid mergeinfo (r1028108) > > * fix abort in 'svn blame -g' (issue #3666) > > > > Can you try to back out each of them to see if the problem persists? > > The problem goes away if I reverse merge r1028108. The only source > file that changed in that revision is subversion/libsvn_repos/log.c > > The 1.6.15 error log records a "File not found: revision xyz, path '...'" > And it is true, because that file specified in the path part > was renamed during the history. So the file existed, just not > with the current name. That leads me to believe something > is not following the copyfrom history correctly, or it is using > the "current" filename when it should be using the file > as it was named in that revision. > > Hopefully someone more familiar with the code can identify > the problem faster, but I'll continue to look at it. Increasing MAX_OPEN_HISTORIES in log.c to 128 allows the command to work for my test repository, so it is definitely a problem with files with complicated history. Kevin R.
