You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Justin Johnson <ju...@gmail.com> on 2012/03/01 14:45:08 UTC
Re: predecessor count for the root node-revision is wrong message
On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson <ju...@gmail.com>wrote:
> On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf <da...@elego.de> wrote:
>
>> Justin Johnson wrote on Wed, Feb 29, 2012 at 11:11:18 -0600:
>> > On Wed, Feb 29, 2012 at 10:35 AM, Daniel Shahaf <da...@elego.de>
>> wrote:
>> >
>> > > Justin Johnson wrote on Wed, Feb 29, 2012 at 10:25:38 -0600:
>> > > > On Wed, Feb 29, 2012 at 10:15 AM, Daniel Shahaf <da...@elego.de>
>> > > wrote:
>> > > > > - Are the failing revisions always small (eg: just a URL-URL
>> copy),
>> > > > > or always large (eg: results of a merge)?
>> > > > >
>> > > > >
>> > > > As mentioned before, so far it appears to be 1) create a tag by
>> copying
>> > > an
>> > > > entire working copy of a branch to a URL, and 2) commit merge
>> results for
>> > > > an entire branch.
>> > > >
>> > >
>> > > That's not clear enough. Could you show 'log -qv' of those revisions?
>> > >
>> > > A wc-to-URL copy could touch just one or two files (compare
>> > > `svn log -qv --stop-on-copy
>> > > http://svn.apache.org/repos/asf/subversion/tags/1.7.3`<http://svn.apache.org/repos/asf/subversion/tags/1.7.3>
>> )
>> > > or a full tree (http://subversion.apache.org/faq.html#in-place-import
>> ).
>> > > Which is it?
>> > >
>> > >
>> > The commits fail, so there is no revision to run this against. Other
>> tags
>> > that have succeeded seem to just have one added path that is a copy of
>> the
>> > branch at revision x. Does that answer your question?
>> >
>>
>> Yes, thanks.
>>
>> >
>> > > >
>> > > > > - Could you try setting the maximum cache size to zero?
>> (svnserve:
>> > > > > --memory-cache-size=0; mod_dav_svn: SVNInMemoryCacheSize 0)
>> > > > >
>> > > > >
>> > > > Apache is our server, so this is not applicable.
>> > >
>> > > SVNInMemoryCacheSize is applicable.
>> > >
>> >
>> > Sorry, I missed that one. We have not specified SVNInMemoryCacheSize,
>> so
>> > we're using the default.
>>
>> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
>> issue less frequent.
>>
>
> I'm a dork. I will do so once I take care of the appropriate change
> control I have to deal with. Thanks.
>
We made the change and problem is still occurring.
Re: predecessor count for the root node-revision is wrong message
Posted by Daniel Shahaf <da...@elego.de>.
Justin Johnson wrote on Thu, Mar 01, 2012 at 08:28:20 -0600:
> To make sure I understand the issue, should I be concerned about the
> repositories and our ability to reproduce the history or recover from any
> corruption that this bug may have caused?
The only known (and predicted) effect of the error is that some
revisions are wrongly skipped during a backward history walk --- such as
'log -r HEAD:0' does.
Creating an svnsync mirror is enough to fix the issue. (There is no
need to check the mirror, even: if the mirror is written to by a 1.7
server (or a 1.7 svnsync over file://), the normal validation that
Jason's error logs show will be done automatically.)
Re: predecessor count for the root node-revision is wrong message
Posted by Justin Johnson <ju...@gmail.com>.
On Fri, Mar 2, 2012 at 3:41 AM, Daniel Shahaf <da...@elego.de> wrote:
> Justin Johnson wrote on Thu, Mar 01, 2012 at 07:45:08 -0600:
> > On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson <
> justinandtonya@gmail.com>wrote:
> > > On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf <da...@elego.de>
> wrote:
> > >> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
> > >> issue less frequent.
> > >>
> > >
> > > I'm a dork. I will do so once I take care of the appropriate change
> > > control I have to deal with. Thanks.
> > >
> >
> > We made the change and problem is still occurring.
>
> OK. So that means that either membuffer isn't the cause of the error,
> or both membuffer and inprocess have (independent) bugs.
>
> That said, I'm happy to see that it took you less than a day to report
> that the bug no longer reproduces. Can you reproduce it at will?
>
>
No, but our server has about 2500 active users on it, so it doesn't take
long to see errors. If we make a configuration change and a day goes by
without the error showing up in the logs I would suspect the problem was
fixed. If a week were to pass with no error I would feel much more
confident.
Yesterday had 6 of the errors and 1 today so far.
Re: predecessor count for the root node-revision is wrong message
Posted by Daniel Shahaf <da...@elego.de>.
Justin Johnson wrote on Thu, Mar 01, 2012 at 07:45:08 -0600:
> On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson <ju...@gmail.com>wrote:
> > On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf <da...@elego.de> wrote:
> >> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
> >> issue less frequent.
> >>
> >
> > I'm a dork. I will do so once I take care of the appropriate change
> > control I have to deal with. Thanks.
> >
>
> We made the change and problem is still occurring.
OK. So that means that either membuffer isn't the cause of the error,
or both membuffer and inprocess have (independent) bugs.
That said, I'm happy to see that it took you less than a day to report
that the bug no longer reproduces. Can you reproduce it at will?
---
I'm not completely sure what to try next. Were there any other
significant changes in 1.6.x->1.7.x besides caching? If so, the
next steps would be to disable _both_ inprocess and membuffer, or
to bisect.
Unfortunately, the latter requires building svn from source, and the
former requires either that, or having you upgrade to specially-built
binaries, or squeezing the "disable inprocess" feature into 1.7.4 (in
a way that doesn't break our compat policy too badly) and having you
upgrade to that.
devs/all --- thoughts? Is there a simpler way forward than the two
potential 'next step's I've outlined here?
Re: predecessor count for the root node-revision is wrong message
Posted by Justin Johnson <ju...@gmail.com>.
>
> > > > > - Are the failing revisions always small (eg: just a URL-URL copy),
>>> > > > > or always large (eg: results of a merge)?
>>> > > > >
>>> > > > >
>>> > > > As mentioned before, so far it appears to be 1) create a tag by
>>> copying
>>> > > an
>>> > > > entire working copy of a branch to a URL, and 2) commit merge
>>> results for
>>> > > > an entire branch.
>>> > > >
>>> > >
>>> > > That's not clear enough. Could you show 'log -qv' of those
>>> revisions?
>>> > >
>>> > > A wc-to-URL copy could touch just one or two files (compare
>>> > > `svn log -qv --stop-on-copy
>>> > > http://svn.apache.org/repos/asf/subversion/tags/1.7.3`<http://svn.apache.org/repos/asf/subversion/tags/1.7.3>
>>> )
>>> > > or a full tree (
>>> http://subversion.apache.org/faq.html#in-place-import).
>>> > > Which is it?
>>> > >
>>> > >
>>> > The commits fail, so there is no revision to run this against. Other
>>> tags
>>> > that have succeeded seem to just have one added path that is a copy of
>>> the
>>> > branch at revision x. Does that answer your question?
>>> >
>>>
>>> Yes, thanks.
>>>
>>> >
>>> > > >
>>> > > > > - Could you try setting the maximum cache size to zero?
>>> (svnserve:
>>> > > > > --memory-cache-size=0; mod_dav_svn: SVNInMemoryCacheSize 0)
>>> > > > >
>>> > > > >
>>> > > > Apache is our server, so this is not applicable.
>>> > >
>>> > > SVNInMemoryCacheSize is applicable.
>>> > >
>>> >
>>> > Sorry, I missed that one. We have not specified SVNInMemoryCacheSize,
>>> so
>>> > we're using the default.
>>>
>>> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
>>> issue less frequent.
>>>
>>
>> I'm a dork. I will do so once I take care of the appropriate change
>> control I have to deal with. Thanks.
>>
>
> We made the change and problem is still occurring.
>
The error occurs when a tag is created by copying from a URL to a URL as
well. Note that the clients are all 1.6 at this time. If it is helpful I
can try to setup some tests with a 1.7 client.
To make sure I understand the issue, should I be concerned about the
repositories and our ability to reproduce the history or recover from any
corruption that this bug may have caused?
Let me know if I can help in any other way.
Thanks.
Justin