kmradke_at_rockwellcollins.com wrote on 01/20/2011 02:26:02 PM:
> Stefan Sperling <stsp_at_elego.de> wrote on 12/16/2010 03:11:03 PM:
> > On Thu, Dec 16, 2010 at 02:50:27PM -0600, kmradke_at_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.
Received on 2011-01-20 23:49:34 CET