From: Nico Kadel-GarciaOn Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas <email@example.com> wrote:
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 (http://svn.borg.ch/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,
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.
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.