Relocate and externals URLs

[John Danning]

We recently relocated our svn repos to a new server.

During the relocation we ran a script which changed all our old absolute URLs for externals into the new style relative URLs.

This all worked fine and I can see the new relative URLs if I use the repo-browser, or if I do a completely fresh checkout. However, there seems to be absolutely no way to get tortoise svn client to see these changed URLs when using an existing checkout. They are all pointing at the old server when viewed from TortoiseSVN->Properties window.

Does anyone know how to get this to work on an existing checkout?

[Niemann, Hartmut]

Hi John,

 

As an external is a directory’s property, I would suspect that – if you committed the changes made by the script – a simple

svn relocate for the base WC and an svn update would do the trick.

This would update the properties, and then – after changing those properties – would loop over all externals and fix those.

Or am I missing anything important?

 

Hartmut

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/dbceebd8-99be-4a41-8872-07cbcddb5e04n%40googlegroups.com.

[John Danning]

Hi Hartmut,

You'd think that would work, but it didn't! Tortoise svn client is still showing the old externals URLs in the properties dialog box, but if I look at the same properties in the repo-browser it shows the new URLs.

It's like tortoise has some data cached somewhere which it's refusing to update.

[Johan Corveleyn]

Hi John,

You said "During the relocation we ran a script which changed all our

old absolute URLs for externals into the new style relative URLs."

The question is: did you do this with new commits, changing the
"svn:externals" properties in new revisions? Or did your script change
the properties "in history" (e.g. by executing a dump + manipulation +
load), effectively rewriting history?

If you did the latter, then you have invalidated all existing working
copies, and all your users should get new checkouts. You must regard
the relocated (and rewritten) repository as a new repository (and must
give it a new repos UUID).
SVN cannot cope with rewriting history. The existing working copies
think they are up to date (so no reason to fetch the changed
properties from the server), and the clients have no way to know that
history was rewritten.

If you did the changes to svn:externals properties with new additional
commits, then there should be no problem (if that is really the case,
then I don't understand what's going wrong either).

--
Johan

> To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/de2fea77-8284-47ae-9b06-065093a246ban%40googlegroups.com.

[Bruce C]

Hi,

In the past, I too have modified externals on server side to change them from fully specified to relative. This was done by dumping the repo, making the changes and then reloading the modified dump file. At that time, I advised our users to remove local copies and perform a fresh checkout. As I recall, some users didn't do that and the old externals got recommitted.

The problem is that you've changed the repository state in a way that the Subversion clients don't expect. For example, if the working copy checkout is at r1000, it is expected that the server state for r1000 is the same. With the changes you've made, all the working copies are out of sync with the server. The obvious solution is to ensure that all users delete existing working copies and get a clean checkout.

I'm no expert but it seems to me that there's a difference between relocate and externals. The relocate option basically updates the local meta information associated with the working copy to change the server location associated with the working copy. However, the externals are defined as a property. That is, external properties are content of the working copy. When you switch or relocate I wouldn't expected content changes to be made for the local working. This would seem to be true whether the content changes are to a source code file or an external property of a working copy folder.

The simplest solution would be to ensure that users delete existing checkouts and get a new, clean checkout from the new server. If there are local changes that need to be moved across, one option would be to create a patch from the current checkout and then apply it to the clean checkout. Just check that the externals weren't included in the patch. I don't know but I suspect the patch is created against the local pristine copy (that will still have the old externals) so the old externals won't show as a change. However, the patch might be created against the server state (with the new externals) so the old externals will show as a change.

That's how I see it. I may be wrong. If I am, I'll learn something too when someone points out the error in my thinking. :-)

Hope this helps.

[John Danning]

Hi Johan and Bruce,

Your explanations make perfect sense. I will just recommend that all the developers do fresh checkouts from this point on.

Thanks,

John.