subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nico Kadel-Garcia <>
Subject Re: Moving a repository with svn:externals using absolute paths (URLs)
Date Thu, 19 Jun 2014 01:19:57 GMT
On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas <> wrote:

>  Hi,
> We’ve been using svn successfully for years on a server, and now have to
> migrate to a new one. We are hit by the known issue of svn:externals
> containing absolute paths to the repo to be moved, since we started with
> versions <1.5 without support for relative URLs.
> We’ve been researching how to properly do this, knowing that we handle
> certified SW on that server, so losing data or corrupting the repo is not
> allowed, and we want to be able to go back in time and checkout an old
> state at any time.
> We’ve experimented the svndumptool (
> referenced for instance in this post:
> It seems to be the only tool doing what we want, and it apparently works,
> but before doing the change on the production repo we’d like to know what
> experiences there are with this tool, and if  it’s safe to use – or if
> there is a better alternative.
> Thanks for your feedback if you have any experience with this,
> Nicolas
The simple answer I'd recommend is "don't". The amount of time you are
going to spend trying to cross migrate old build environments is expensive,
fragile, and requires polluting your history to generate a new, and
misleading one, pointing to the correct SVN server.

Set aside the legacy configuration, incompatible as it is with modern
"relative" URL's, for reference and log analysis only. Keep it pristine,
and don't muck with the history. Bring only the relevant components to your
new server, on a scheduled cutover date, and take the opportunity to
discard bulky binaries and branches and logs and security sensitive debris
with the move to a new server with a new URL. Drop a README.txt in place on
the new server pointing to the old, legacy repository, and kick it aside.

If your employers or clients cannot accept this, create migration branches,
and tags as soon as you do the replication, with the safe new
"svn:externals" settings. This is much safer than manipulating the old
logs: once you get into manipulating logs, it's like cross-breeding puppies
from the same litter: you may get the champion you want, but the practice
can also lead to a lot disasters which will be blamed on the editing, even
if it's not really the source of the problem.

View raw message