________________________________ From: Nico Kadel-Garcia On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas <nicolas.bris...@airbus.com<mailto:nicolas.bris...@airbus.com>> 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 (http://svn.borg.ch/svndumptool/) referenced for instance in this post: http://stackoverflow.com/questions/204616/how-to-migrate-all-urls-in-svnexternals-properties-across-a-repository 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 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. Regards, Geoff -- 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.
