Moving SVN from one server to another

[Paul Greene <pa...@gmail.com>]

Hello,

I need to move a subversion deployment from an ancient Redhat server to a
new Centos7 server.

The old subversion server is running version 1.4.6-1. The new server is
running 1.7.14-11.

There's 110 different repositories on the old server, so I'm looking for an
efficient way to move all of the old repositories to the new server.

The old server has its repositories under "/data/subversion", so I created
the same folder and sub-folder on the new server.

Is it possible to do an NFS share of the /data/subversion folder on the new
server, mount that share on the old server and just "cp -R --preserve * "
to the new server to keep the same permissions and ownership? Will all the
repos work correctly if copied over in that way?

I tried a test of a couple of repo folders and it seemed to copy over and
keep all the correct permission/ownership settings, but I'm not sure if the
repos will still work correctly without doing something additional to them.

Thanks,

PG

Re: Moving SVN from one server to another

[Ryan Schmidt <su...@ryandesign.com>]

On Apr 23, 2018, at 17:19, Paul Greene wrote:

> The old subversion server is running version 1.4.6-1. The new server is running 1.7.14-11.

Consider that Subversion 1.8.x and earlier are end-of-life. The current version is 1.10.0.

https://subversion.apache.org/docs/release-notes/1.10.html#svn-1.8-deprecation

Re: Moving SVN from one server to another

[Bo Berglund <bo...@gmail.com>]

On Thu, 26 Apr 2018 13:48:18 -0400, Nico Kadel-Garcia
<nk...@gmail.com> wrote:

>Bingo. It is, theoretically, possible to individually bring commits
>done directly on the slave back over to the original master to resolve
>such a resulting split brain.

And this is described in the svn-book too.

But when I set up my mirror I decided against it because the involved
hooks looked potentially slow to me. And I just needed to safeguard
the master in a completely different location as a backup.
So I installed a nightly cron job to do the sync once every 24 hours
rather than immediately upon commit to master by utilizing the
post-commit hook.


-- 
Bo Berglund
Developer in Sweden

Re: Moving SVN from one server to another

[Nico Kadel-Garcia <nk...@gmail.com>]

On Thu, Apr 26, 2018 at 5:58 AM, Bo Berglund <bo...@gmail.com> wrote:
> On Thu, 26 Apr 2018 11:26:38 +0200, OBones <ob...@free.fr> wrote:
>
>>Well, maybe I read this wrong, but the manual talks about a master and a
>>slave, which are tightly related. If I remove the master once the slave
>>is fully ready to take over its role, I'm not sure it will work
>>smoothly, hence my question.
>
> I just set up an svnsync system a few weeks back and my read is that
> the two repositories are basically mirror images of each other, but
> that the mirror should never be committed to.
> (Except for svnsync of course, it will shoot the commits performed on
> the master to the mirror thus replicating the state)

The mirror should never be committed to, until and unless any planned
migration is complete and the original master is disabled.

> But if you decide to take the master off-line at a later time and run
> with the mirror instead, then what you need to do is modify the hooks
> that are present on the mirror to disallow commits except from svnsync
> and whatever sync related hooks you have in place.
> After that the mirror should act as a regular repository, but you can
> no longer sync with the original because of colliding revision
> numbers.

Bingo. It is, theoretically, possible to individually bring commits
done directly on the slave back over to the original master to resolve
such a resulting split brain. But it's safer to set up a slave of the
slave, rely on that for failover, and shoot the original master server
through the head.

Nico Kadel-Garcia <nk...@gmail.com>

>
> --
> Bo Berglund
> Developer in Sweden
>

Re: Moving SVN from one server to another

[Bo Berglund <bo...@gmail.com>]

On Thu, 26 Apr 2018 11:26:38 +0200, OBones <ob...@free.fr> wrote:

>Well, maybe I read this wrong, but the manual talks about a master and a 
>slave, which are tightly related. If I remove the master once the slave 
>is fully ready to take over its role, I'm not sure it will work 
>smoothly, hence my question.

I just set up an svnsync system a few weeks back and my read is that
the two repositories are basically mirror images of each other, but
that the mirror should never be committed to.
(Except for svnsync of course, it will shoot the commits performed on
the master to the mirror thus replicating the state)

But if you decide to take the master off-line at a later time and run
with the mirror instead, then what you need to do is modify the hooks
that are present on the mirror to disallow commits except from svnsync
and whatever sync related hooks you have in place.
After that the mirror should act as a regular repository, but you can
no longer sync with the original because of colliding revision
numbers.


-- 
Bo Berglund
Developer in Sweden

Re: Moving SVN from one server to another

[OBones <ob...@free.fr>]

Ryan Schmidt wrote:
> On Apr 25, 2018, at 07:15, OBones wrote:
>
>> Nico Kadel-Garcia wrote:
>>> In general, to jump that many major revisions, I tend to use "svnsync"
>>> to allow the repositories to stay synchronized while the client stays
>>> talking to the first repository, then take the first repository
>>> entirely offline. Note that this is probably the first opportunity, in
>>> years, to obliterate content from the old repositories "and reset the
>>> ID of the new repository, to avoid clients getting confused about
>>> obliterated content.
>> Setting up the svnsync is explained in the manual, but how do you "turn it off" of afterwards?
> svnsync synchronizes every time you run it. If you don't want to synchronize anymore, simply don't run it again.
>
Well, maybe I read this wrong, but the manual talks about a master and a 
slave, which are tightly related. If I remove the master once the slave 
is fully ready to take over its role, I'm not sure it will work 
smoothly, hence my question.

Re: Moving SVN from one server to another

[Ryan Schmidt <su...@ryandesign.com>]

On Apr 25, 2018, at 07:15, OBones wrote:

> Nico Kadel-Garcia wrote:
>> In general, to jump that many major revisions, I tend to use "svnsync"
>> to allow the repositories to stay synchronized while the client stays
>> talking to the first repository, then take the first repository
>> entirely offline. Note that this is probably the first opportunity, in
>> years, to obliterate content from the old repositories "and reset the
>> ID of the new repository, to avoid clients getting confused about
>> obliterated content.
> Setting up the svnsync is explained in the manual, but how do you "turn it off" of afterwards?

svnsync synchronizes every time you run it. If you don't want to synchronize anymore, simply don't run it again.

Re: Moving SVN from one server to another

[OBones <ob...@free.fr>]

Nico Kadel-Garcia wrote:
> In general, to jump that many major revisions, I tend to use "svnsync"
> to allow the repositories to stay synchronized while the client stays
> talking to the first repository, then take the first repository
> entirely offline. Note that this is probably the first opportunity, in
> years, to obliterate content from the old repositories "and reset the
> ID of the new repository, to avoid clients getting confused about
> obliterated content.
Setting up the svnsync is explained in the manual, but how do you "turn 
it off" of afterwards?

Re: Moving SVN from one server to another

[Nico Kadel-Garcia <nk...@gmail.com>]

On Mon, Apr 23, 2018 at 7:33 PM, Eric Johnson <er...@tibco.com> wrote:
> It should be OK to use rsync, so long as the "old server" is not in use and
> the repositories are not being modified while you're syncing them.
>
> Then, I strongly recommend a dump and load on the new server.
>
> Eric.

The "permissions" may not be what you expect if there is a discrepancy
between usernames and uuids. "cp" and "scp" don't preserve SELinux
permissions, which may matter if the Subversion repository is being
served as a web service. If I were working with "rsync", I'd use these
commands to do a dry-run first, then an rsync.


In general, to jump that many major revisions, I tend to use "svnsync"
to allow the repositories to stay synchronized while the client stays
talking to the first repository, then take the first repository
entirely offline. Note that this is probably the first opportunity, in
years, to obliterate content from the old repositories "and reset the
ID of the new repository, to avoid clients getting confused about
obliterated content.

Re: Moving SVN from one server to another

[Eric Johnson <er...@tibco.com>]

It should be OK to use rsync, so long as the "old server" is not in use and
the repositories are not being modified while you're syncing them.

Then, I strongly recommend a dump and load on the new server.

Eric.

On Mon, Apr 23, 2018 at 3:19 PM, Paul Greene <pa...@gmail.com>
wrote:

> Hello,
>
> I need to move a subversion deployment from an ancient Redhat server to a
> new Centos7 server.
>
> The old subversion server is running version 1.4.6-1. The new server is
> running 1.7.14-11.
>
> There's 110 different repositories on the old server, so I'm looking for
> an efficient way to move all of the old repositories to the new server.
>
> The old server has its repositories under "/data/subversion", so I created
> the same folder and sub-folder on the new server.
>
> Is it possible to do an NFS share of the /data/subversion folder on the
> new server, mount that share on the old server and just "cp -R --preserve *
> " to the new server to keep the same permissions and ownership? Will all
> the repos work correctly if copied over in that way?
>
> I tried a test of a couple of repo folders and it seemed to copy over and
> keep all the correct permission/ownership settings, but I'm not sure if the
> repos will still work correctly without doing something additional to them.
>
> Thanks,
>
> PG
>