On 7/26/2011 9:48 AM, Stefan Sperling wrote:
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)?
The original copy was over a local area network, using "tar cf - | ssh"
on the 64-bit machine and pushing the files to the 32-bit machine. My
notes then say something to the effect of "trouble - redone with dump
and load cycle". This was in January 2007 with Subversion 1.3.0 on both
ends. I never tried the directory copy again. I don't have better
notes about what problems I found.
The FSFS spec links are interesting and on first reading suggest
portability, but I don't have enough time to study them in detail. I'd
have to look at all of the specs for repository files to be sure. For
now I back up my repositories nightly using hot copies and full dumps
(about 2 GB total dump size, so still feasible). One of the
repositories came from a remote hosting service via svnsync; we decided
that local hosting was better. I don't use svnsync locally now because
all but one of my machines are powered off at night, but it worked
without any problems then.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
