Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of nkadel@gmail.com designates
 209.85.160.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EA7EDC2.10706@jibbyjobby.co.uk>
References: <4EA7EDC2.10706@jibbyjobby.co.uk>
Date: Fri, 28 Oct 2011 19:59:36 -0400
Message-ID: 
 <CAOCN9rxuL_X_tkXdKObfQ2cZF5njo7cGfOjGuxs-u9t458WKFw@mail.gmail.com>
Subject: Re: SVN repo cross-platform compatibility
From: Nico Kadel-Garcia <nkadel@gmail.com>
To: Neil Bird <neil@jibbyjobby.co.uk>
Cc: users@subversion.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 26, 2011 at 7:23 AM, Neil Bird <neil@jibbyjobby.co.uk> wrote:
>
> =A0Whilst suffering a subversion server outage, it's made me wonder: =A0w=
e
> currently produce nightly backups of our repos via 'hotcopy' from the
> server's local drive to a network store.
>
> =A0If the server were to die, would I be able to take those copies and pl=
ace
> them under a server on a new box *with a different OS*? =A0Or would I hav=
e to
> create a temporary server with the original OS, copy them to that, and
> svndump them and import them elsewhere?
>
> =A0In this case, it's a Solaris server, dunno what processor [I'll check =
when
> it's back up!], and I'd consider moving it to an x86 Linux server.

Never do this by direct filesystem replication. "hotcopy" is somewhat
better. Issues with transfer via hotcopy include the fact that hotcopy
*does not* replicate file permissions and file ownership, it simply
copies them as whoever runs the "svnadmin hotcopy" command. That can
cause *enormous* problems in various configurations. And between
operating systems, the "hook" or "conf" tools that are incompatible
between the system's scripting languages. Worse, if your new OS does
not have an equal or greater Subversion major release, the hotcopy
will likely be incompatibile with the new OS.

I spent one *hell* of a time last year, when someone had been running
a handbuilt Subversion binary with a manually built and awkwardly
configured service, and I was prevented by "policy" from updating the
Subversion on RHEL 5.x, which was Subversion 1.4.x, to the publicly
available Subversion 1.6.x from RPMforge. So I was compelled for
political reasons, not techinical reasons, to continue to support the
older and more fragile environments, and not permitted to migrate them
for quite a long time.

That said, you also face a very dangerous "split brain" issue if you
simply set up the replicated, up to 24 hours out of date copy
elsewhere and set up the same uuid, so users who've already checked
out or checked in changes since the last snapshot will have a local
working copy that is dangerously out of sync with the replica.  Two
diferent working copies can wind up with different ideas of whatever
revisions occurred, and may wind up out of sync between the two
repositories.

All that said, Solaris=3D>Linux is fortunately a fairly easy migration.
Similar releases of Subversion are available, unless you have a
seriously out of date system that policy forbids you from updating.
The trick is to keep the *non* db files, the hooks and conf files,
mirrored separately and regularly, and keep a Linux read-only
repository mirrored with "svnsync", Properly managed, the "svnsync"
can even be triggered to occur after every successful commit, and
always keep you within one revision of the master repository.

If you have to do the replica, *use a new uuid* and inform your users
that they have to deal with a new repository.