On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson <justinandtonya_at_gmail.com>wrote:
> On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf <danielsh_at_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 <danielsh_at_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 <danielsh_at_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.
Received on 2012-03-01 14:45:41 CET