subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Field <>
Subject RE: Moving a repository with svn:externals using absolute paths (URLs)
Date Thu, 19 Jun 2014 01:35:44 GMT

From: Nico Kadel-Garcia

On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas <<>>
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,
Hi Nicolas,

We upgraded from 1.2 to 1.8 in one fell swoop.  We don't use externals, which made things
easier.  However, most of our 1.2 repositories were in BDB format, which off-the-shelf Windows
binaries of 1.8 don't handle.  (I am somewhat averse to trying to recompile for Windows, as
that would entail finding and setting up the correct compilation environment for it - too
much like work.)

I wrote a batch file to do a dump, reload and rename on each repository.  Basically, the old
repositories were left in place, but with the name changed to append "_BDB" and the re-loaded
repositories in FSFS format run live.  Full history now lives in both sets of repositories,
with the BDB versions retained in case we ever need to go back and double-check.

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.

This is basically what we did, but without mucking about to edit dump files, etc.  As Nico
says, keep the originals pristine.  Disk space is cheap (although backup on alternative storage
might not be).
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.
There's also the point that any editing you do is (a) prone to human error and (b) likely
to consume large amounts of your time.

In our duplication effort, we also set all the permissions on the old repositories to read-only,
to limit the chances of cross-contamination.



Apologies for the auto-generated legal boilerplate added by our IT department:

- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 

View raw message