On Mon, Jul 9, 2012 at 1:40 AM, Bert Huijben <b...@qqmail.nl> wrote: > > > > -----Original Message----- > > From: stef...@apache.org [mailto:stef...@apache.org] > > Sent: zondag 8 juli 2012 18:50 > > To: comm...@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
