----- Original Message ----
> From: Ryan Schmidt <subversion-2010b_at_ryandesign.com>
> To: BRM <bm_witness_at_yahoo.com>
> >> Since the UUID has changed, everyone must check out new working copies; it
> >> not possible to update or switch existing working copies to this new
> >> repository.
> > Or I could just ignore the history, and just go back to my original question
> > changing the values.
> > As I said, I need to make this as seamless as possible for everyone -
> > doing an 'svn relocate'/'svn update' on the working copies.
> And as I said, dump and load and changing UUID requires checking out new
> 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
> 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
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
> > 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
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.
Received on 2010-09-04 00:52:55 CEST