HI Ryan, thanks for your help. I have found more information.
Apparently my IT admins have two different version of SVN installed. The
svn/apache/apr installation uses APR 0.9.12. But another svn/apr
installation exists that uses APR 0.9.4. The hook scripts use the binaries
from this installation. This is the source of the hook scripts' inability
to access the repository after a 2+ GB revision was committed.
Anyway, can I tell my IT to upgrade that second svn install to APR 0.9.12 or
is 1.2 really required? It seems like 0.9.12 is working okay. If I need
them to upgrade to APR 1.2 it is a much bigger deal since this affects the
whole LAMPP stack.
To ward off the comment that I know will be coming: Yes, I know you can't
mix APR versions. SVN and Apache are both using APR 0.9.12. It is just
that there is a second SVN install (no Apache) that uses APR 0.9.4.
thanks,
David
On 10/12/07, Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
>
> As per my earlier message (which you quoted below), APR 0.9 is "old"
> and doesn't like revisions larger than 2GB. APR 1.2 is "new" and
> doesn't have this problem. But you said you're using Apache 2.2 so
> I'm not sure how you're even using APR 0.9 with it. They're not
> compatible. Apache 2.2 requires APR 1.2. And your Subversion should
> always be compiled using the same APR as your Apache.
>
>
> On Oct 12, 2007, at 13:47, David Ferguson wrote:
>
> > Could this have something to do with the version of APR? I keep
> > finding various forum posts that allude to problems with large
> > files and old versions of APR. We're using APR 0.9.12 which seems
> > pretty recent.
> >
> > On 10/12/07, David Ferguson <ferguson.david@gmail.com> wrote: Okay,
> > I've narrowed down the problem. If I run the following command on
> > a 32-bit machine running RHEL4p4, it fails:
> >
> > $ /tools/bin/svnlook changed /home/svn/svnrepo_links/xyz -r 5454
> > svnlook: Can't set position pointer in file '/home/svn/
> > svnrepo_links/xyz/db/revs/5454': Value too large for defined data type
> >
> > If I run the same command on a 64-bit machine running RHEL4p4, the
> > above command works.
> >
> > Why would 32 vs. 64 matter? Is there a limit in Subversion?
> > Again, I'm using Subversion 1.4.3 and db/revs/5454 is a 2.6G file.
> >
> > thanks,
> > David
> >
> >
> >
> > On 10/12/07, Srilakshmanan, Lakshman <
> > lakshman.srilakshmanan@police.vic.gov.au> wrote:Hi
> >
> > > The svn server is running RHEL 4, update 4 with Apache 2.2.3 and
> > > Subversion 1.4.3. Repository is mounted over NFS.
> >
> > Wouldn't mounting a repository over NFS result in repository
> > corruption.
> >
> > Thanks
> > lakshman
> > -----Original Message-----
> > From: Ryan Schmidt [mailto: subversion-2007b@ryandesign.com]
> > Sent: Friday, 12 October 2007 2:51 PM
> > To: David Ferguson
> > Cc: Subversion Mailing List
> > Subject: Re: Help! Urgent problem.
> >
> > On Oct 11, 2007, at 22:15, David Ferguson wrote:
> >
> > > A user just checked in a very large commit in r5454. The db/revs/
> > > 5454 file
> > > is 2.6G. Now, when anyone tries to make another commit, they get
> > this
> >
> > > error from the pre-commit hooks:
> > >
> > > svn: 'pre-commit' hook failed with error output:
> > > /tools/bin/svnlook changed /home/svn/svnrepo_links/xyz -t 5454-1
> > > svnlook: Can't set position pointer in file
> > > '/home/svn/svnrepo_links/xyz/db/revs/5454': Value too large for
> > > defined data type
> > >
> > > I disabled my pre-commit and was able to make another commit, but
> > then
> >
> > > then the post-commit scripts failed in the same way.
> > >
> > > Updates seem to work just fine.. What the heck is going on here?
> > >
> > > The svn server is running RHEL 4, update 4 with Apache 2.2.3 and
> > > Subversion 1.4.3. Repository is mounted over NFS.
> >
> > APR 0.9 had problems with files (hence: revisions) > 2 GB, but Apache
> > 2.2.x uses APR 1.2 which doesn't have that problem.
> >
> > Does your filesystem have problems with files that large?
> >
> > What are the pre- and post-commit scripts doing?
>
Received on Mon Oct 15 23:23:16 2007