On Mon, Jul 9, 2012 at 1:40 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> > Sent: zondag 8 juli 2012 18:50
> > To: commits_at_subversion.apache.org
> > Subject: svn commit: r1358779 -
> > /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
> >
> > Author: stefan2
> > Date: Sun Jul 8 16:49:31 2012
> > New Revision: 1358779
> >
> > URL: http://svn.apache.org/viewvc?rev=1358779&view=rev
> > Log:
> > Fix revprop access code on systems where apr_off_t (mainly 32 bit
> > machines)
> > is different from apr_size_t. Use apr_off_t consistently for the size and
> > offset values stored in the revprop packs.
>
> Wasn't the fsfs fileformat architecture independent before this change?
>
> It still is. The problem was with the runtime presentation
of the pack file content.
> My information is probably outdated, but I expected that we could still
> just copy an fsfs repository between 32 and 64 bit environments and still
> use the same on-disk format. (Maybe even Little endian vs Big endian, but I
> really never checked for that).
>
> If that is still the case we should use explicit 32 bit and 64 bit values
> where necessary.
>
The root cause was a type mismatch caused by
* APR arrays not being type safe
* in-memory object sizes should use apr_size_t
* on-disk object sizes should use apr_off_t
What happened was that I filled an array with apr_off_t
but read it as apr_size_t. So, the element values were
not e.g. "10, 20, 30, 40, 50" but "10, 0, 20, 0, 30".
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-07-09 10:19:10 CEST