----- Original Message ---- > From: Ryan Schmidt <subversion-20...@ryandesign.com> > > $ cat Example1.dump | sed > > 's/file:\/\/\/svnTest\/Example1/file:\/\/\/svnTest\/Example2/' > > > Example1-edited.dump > Do not use sed to edit a dumpfile. Use a tool designed for the task, like >svndumptool. > http://svn.borg.ch/svndumptool/
Why? B/c it might change data in files too? That's actually something I want done. My prime repository has some scripts in it that store the repository information for auto-checkouts as part of build environments, and I want those changed too - not just the svn:externals. Or would sed 'break' the dump file format? svndumptool does look useful to verify that sed did exactly what I wanted - standard diff won't work well on a 2.1 GB dumpfile. > > 5. Load the edited dump into a new repository (Example2) > > > > $ cd /svnTest > > $ svnadmin create Example2 > > $ svnadmin load Example2 < Example1-edited.dump > Because this repository is now different than it was before (the history has >been edited), you must give the new repository a new UUID. > svnadmin load --ignore-uuid Example2 < Example1-edited.dump I wouldn't say 'must' but 'should' - as in 'highly recommended'. > Since the UUID has changed, everyone must check out new working copies; it > is >not possible to update or switch existing working copies to this new changed >repository. Or I could just ignore the history, and just go back to my original question of changing the values. As I said, I need to make this as seamless as possible for everyone - preferably doing an 'svn relocate'/'svn update' on the working copies. Question: If I checked them out again would the client realize that I have a series of files locked and retain the locks on the new working copy? (That would be a PITA to track down if it didn't.) TIA, Ben
