On Sep 3, 2010, at 08:36, BRM wrote: >> 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.
As others said, because if you change the content of files, the checksums won't match. Just use svndumptool to change the svn:externals properties, and for any file content changes, make them and commit them from a working copy as normal. >>> 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'. If the content of the new repository is different from the content of the old repository (and it is, if you changed the properties), then you must give them different UUIDs. That is the sole purpose of the UUID -- to identify when repositories differ. >> 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. And as I said, dump and load and changing UUID requires checking out new working copies. You cannot relocate or update existing working copies. If that's too restrictive, then yes, you'll have to skip the dump and load, just change the externals in HEAD, and accept that you can't check out a past revision and have the externals work. > 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.) I'm not sure exactly what you meant (checked out new working copies? from the new repository?), but note that the dump format does not include information about hook scripts, config files or locks. If you dump and load, the new repository will have the default hook script templates (so, no hook scripts), the default configuration, and nothing locked. But I think you can manually bring the relevant files from the old repository to the new one to preserve this data.
