Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Envelope-To: users@subversion.apache.org
Date: Sat, 30 Mar 2013 12:00:23 +0100
From: =?iso-8859-1?Q?Thorsten_Sch=F6ning?= <tschoening@am-soft.de>
Organization: AM-SoFT IT-Systeme
Message-ID: <3010692137.20130330120023@am-soft.de>
To: users@subversion.apache.org
Subject: Re: SVN repositorires migration using svnsync and master information
 in repos.
In-Reply-To: 
 <CAFMBnF_qCZhdQoKcfnyzcSeYm_j1kNwuw3w=Pv9ahE7FMeMVUw@mail.gmail.com>
References: 
 <CAFMBnF_qCZhdQoKcfnyzcSeYm_j1kNwuw3w=Pv9ahE7FMeMVUw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Guten Tag Ravi Roy,
am Samstag, 30. M=E4rz 2013 um 09:59 schrieben Sie:

> I have verified that all repos on 'new master host' has same revision
> numbers for corresponding repos as on 'master host' . Is that
> guarantees that databases for all repos are migrated successfully to
> 'new master host' ?

No, there was a similar discussion recently:

http://mail-archives.apache.org/mod_mbox/subversion-users/201303.mbox/%3c21=
DA556C6089D34FB2D99CC5FB0422C306BB18EC@lux-mail2.luxembourg.intrasoft-intl.=
private%3e

svnsync will create each revision from your master even if it is not
allowed to read actual data because of path based access restrictions
on the master or simply because you provided a wrong root path on
initializing the repo for syncing. You need to compare repo contents,
e.g. using a client and some svn ls operations or dumping your soiurce
and target repos and comparing their sizes or something similar.

>  -- Do I need remove this master information from
> 'usr/share/repos/Repo-A/db/revprops/0/0' on 'new master host' or it
> does not harm being it a new master subversion server ?

I think it doesn't harm and is easily removable by svnadmin, but
others will know for sure. Besides that, more important to consider is
that your new repos should have got new UUID each, meaning they are
incompatible with your current working copies now. Each working copy
needs to be checked out again, svn relocate doenst work because of the
new UUIDs, you didn't just moved your repos but created new ones, or
you have to manually set the new reop's UUID to the old ones using
svnadmin setuuid. In the latter case you have to make sure that both
repos do have exactly the same content, meaning now revisions
committed after syncing etc.

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning       E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=E4ftsf=FChrer: Andreas Muchow