----- Original Message ---- > From: Ryan Schmidt <subversion-20...@ryandesign.com> > To: BRM <bm_witn...@yahoo.com> > >> 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.
Having the history broken is not much of a problem that way. It just would have been nice to have it work well too. Though, couldn't I setup a script to modify the svn:externals via the pset --revprop option? Any how...I've got a lot of work ahead regardless. > > 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. > Okay - the basic situation is that I have a branch in SVN that was under migration. It was a port of our CVS into SVN and needed to be split up into separate projects which requires a lot of work to do. So I had a working copy where I locked files that I had moved to the new structure to help keep from editing those files in the old structure, and it'll be a PITA to figure out which files were moved and locked between the two. At least I still have the working copy. If they don't transfer, okay - I just have to go through the old working copy and relock them in a new working copy. (I had to use locks as I couldn't just remove the files due to breaking other projects.) Thanks - I think I have my plan of action now - it'll just take a while to implement. If I can get apache to do the proxy thing (http://silmor.de/49) then I can at least get back to a working state where we can move things about with our existing working copies - make sure all changes are in, and are at a good place to re-download them. Sadly this all occurred due to a server crash, so it was rather unplanned though it didn't surprise some of us. Thanks all! Ben