You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by km...@rockwellcollins.com on 2010/12/16 20:50:27 UTC
log -g regression in 1.6.15?
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.
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]
Now this particular file seems to have a long history of being deleted,
recreated with the same name, merged from multiple branches, etc., but
the merge info looks valid and the command runs without errors when
run against a 1.6.13 server.
I'll try and narrow down a test case, but was wondering if
anyone else had seen these errors logged or had ideas
on where the additional "file not found" check might
have been introduced.
Broken server 1.6.15 running under apache 2.2.17 over http.
Working server 1.6.13 running under apache 2.2.17 over http.
Client version does not seem to matter but tried 1.6.5,
1.6.12, and 1.6.15.
The "broken" server does appear to send about 2MB of xml
data before it dies. The "working" server sends 5MB of data.
It does not appear to be caused by a timeout, since it reliably
dies in exactly the same location every time.
Thanks!
Kevin R.
Re: log -g regression in 1.6.15?
Posted by km...@rockwellcollins.com.
Stefan Sperling <st...@elego.de> wrote on 12/16/2010 03:11:03 PM:
> On Thu, Dec 16, 2010 at 02:50:27PM -0600, kmradke@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?
It will probably be a bit before I get a build environment setup to test.
> > I'll try and narrow down a test case,
>
> That would be great.
No success yet, and I realize it is pretty hard to fix
what we don't know the cause...
Kevin R.
Re: log -g regression in 1.6.15?
Posted by km...@rockwellcollins.com.
kmradke@rockwellcollins.com wrote on 01/20/2011 02:26:02 PM:
> Stefan Sperling <st...@elego.de> wrote on 12/16/2010 03:11:03 PM:
> > On Thu, Dec 16, 2010 at 02:50:27PM -0600, kmradke@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.
Re: log -g regression in 1.6.15?
Posted by km...@rockwellcollins.com.
Stefan Sperling <st...@elego.de> wrote on 12/16/2010 03:11:03 PM:
> On Thu, Dec 16, 2010 at 02:50:27PM -0600, kmradke@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.
Kevin R.
Re: log -g regression in 1.6.15?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 16, 2010 at 02:50:27PM -0600, kmradke@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?
> I'll try and narrow down a test case,
That would be great.
> but was wondering if
> anyone else had seen these errors logged or had ideas
> on where the additional "file not found" check might
> have been introduced.
It's probably one of the -g changes above.
Stefan