[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-users
Subject:    Re: Moving Repositories to New server
From:       David Chapman <dcchapman () acm ! org>
Date:       2011-07-26 18:20:54
Message-ID: 4E2F0586.9060005 () acm ! org
[Download RAW message or body]

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@acm.org
     Chapman Consulting -- San Jose, CA


[prev in list] [next in list] [prev in thread] [next in thread]