[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Debian Linux 32 vs. 64 bit

From: David Chapman <dcchapman_at_acm.org>
Date: Mon, 25 Jan 2016 12:33:44 -0800

On 1/25/2016 10:45 AM, Philip Martin wrote:
> David Chapman <dcchapman_at_acm.org> writes:
>
>> On 1/25/2016 3:59 AM, Niemann, Hartmut wrote:
>>> I want to upgrade my Linux box from Debian Jessie (32bit) to Debian
>>> Jessie (64bit).
>>>
>>> For the transition time, the machine will boot alternating the 32bit
>>> and the 64bit OS.
>>>
>>> I have several SVN repositories and working copies on it.
>>>
>>> Is it safe to share SVN repositories and working copies between
>>> 32bit and 64 bit?
>>>
>>> (Jessie ships with 1.8.10, as far as I know.)
> It should just work for both repositories and working copies.

Is that documented somewhere, such that system administrators can rely
on it? Or could a Subversion developer decide to put endian- or
size-dependent binary data into a repository or working copy file somewhere?

>> I wouldn't try this approach for a machine with repositories. I had a
>> repository on a 64-bit Linux machine, then bought a 32-bit micro
>> server that I could keep running all the time. I was unable to copy
>> the repository directory tree directly, even though both were Intel
>> architecture machines. I had to dump and load (with svnadmin). I'd
>> be surprised if this has changed in the last three years.
> It's hard to work out what went wrong from that vague description. In
> the unlikely event that you were using a BDB repository then there are
> BDB library compatibility issues: a recover/upgrade may be needed and
> downgrading to older BDB is not always possible.
>

My notes are vague, unfortunately. This was back in 2007, when I was
compiling from tarballs:

1) configure/compile with BDB support on both platforms
2) copy repository directory to 32-bit machine
3) problem found -> dump/load to avoid system dependencies
4) problem solved
5) hey, my repositories are actually FSFS!

I was trying to take good notes, as is my practice for system
administration tasks that I do once every three years, but somewhere in
the migration process I failed to write something down. Item 5) was
recorded some weeks after the migration, so I don't know when the build
switched to FSFS support only, relative to the repository directory
move. Nor do my notes record what actually got me to a
production-worthy repository. So yes, kind of vague. But enough to get
me spooked.

I also know from experience that it is very easy to let platform
dependencies leak into outside data files. Avoidance takes a concerted
effort and detection is extremely difficult when testing a build on a
single machine (here, by definition we're talking about running a single
repository on two separate machines). Thus my question about a
documented promise from Subversion developers.

-- 
     David Chapman      dcchapman_at_acm.org
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com
Received on 2016-01-25 21:34:03 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.