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 dcchapman_at_acm.org
Chapman Consulting -- San Jose, CA
Received on 2011-07-26 20:22:15 CEST