On Tue, Jul 26, 2011 at 09:22:04AM -0700, David Chapman wrote:
> On 7/26/2011 8:44 AM, Stefan Sperling wrote:
> >On Tue, Jul 26, 2011 at 08:35:31AM -0700, David Chapman wrote:
> >>If the processor architectures differ, copying the repositories
> >>directly won't work unless changes to the repository format have
> >>been made recently. I had a problem when copying a repository from
> >>a 64-bit x86 machine to a 32-bit x86 machine, for example. (I think
> >>this was in 1.4.x, but it was years ago and I don't remember the
> >>details.) Solaris 10 suggests a SPARC machine as the source.
> >>Because of the byte ordering difference, I'd expect major trouble
> >>when copying a repository directly from a SPARC machine to an x86
> >>machine.
> >This only applies to repositories using the BDB backend.
> >There is no such problem with the FSFS backend because it uses flat files.
> >
> >
>
> The bad copy was a FSFS repository. IIRC, the problem was writing
> binary data (e.g. integers) into files. The 64-bit machine wrote
> 64-bit integers into some of the files, and the 32-bit machine got
> confused.
I don't think there are any platform dependent bits in an FSFS revision
file itself. It's much like you can copy, say, a PDF document or a jpg
image via the network from one platform to another and have it work.
Mounting a big-endian filesystem that was written on a sparc on an x86
box is of course a different story. It might work, or it might not.
There is nothing an application can do to account for that though.
It would be good to know what really went wrong in your case.
Maybe something went wrong during the copy process? How was the
repository transferred? Over the network (good idea), or via a disk
that used a big-endian filesystem (possibly a bad idea if the x86
box has no support for reading it properly despite the byte ordering
difference)?
> Unless FSFS writes no binary data into its files, or else it is
> careful to do so in a platform-independent matter, there will be
> trouble. Not being an official Subversion developer, I can't
> comment on the internals of the FSFS format, but I would be very
> surprised if its files were truly platform-independent because this
> would slow down repository operations.
See the spec here if you want to know the details:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
Some related links:
https://svn.apache.org/repos/asf/subversion/trunk/notes/svndiff
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/structure (BDB spec)
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history
> Given that there is an
> official portable transfer file format (the dump file), I would
> expect the Subversion developers to use more-efficient non-portable
> code within the repository files.
It is more about being able to switch between backends and to allow
upgrades to versions that change the repository format in non-trivial ways.
> You can certainly try to copy one repository directly from one
> platform to the other, then run "svnadmin verify". That *should*
> tell you if there was a problem.
Yes, indeed.
> But I wouldn't trust anything
> worth money on an inter-platform repository file copy.
I suppose it depends on how that copy is done.
Received on 2011-07-26 18:49:40 CEST