[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Scripting an svn:externals change

From: BRM <bm_witness_at_yahoo.com>
Date: Fri, 3 Sep 2010 15:52:17 -0700 (PDT)

----- 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
>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
Received on 2010-09-04 00:52:55 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.