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. On Tuesday, 17 November 2020 at 08:52:52 UTC [email protected] wrote: > 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. > > On Monday, November 16, 2020 at 3:34:58 PM UTC H. Niemann wrote: > >> 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 >> >> >> >> >> >> *Von:* John Danning via TortoiseSVN <[email protected]> >> *Gesendet:* Montag, 16. November 2020 11:47 >> *An:* TortoiseSVN <[email protected]> >> *Betreff:* Relocate and externals URLs >> >> >> >> 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? >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tortoisesvn/dbceebd8-99be-4a41-8872-07cbcddb5e04n%40googlegroups.com >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Ftortoisesvn%2Fdbceebd8-99be-4a41-8872-07cbcddb5e04n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Chartmut.niemann%40siemens.com%7C3327bf4aaceb4e25b6d308d88a1cf42b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637411204241613513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O2ffver6Lr82LxUj1oAP4hnZP9sCOSi0Msc0mtgpE%2B4%3D&reserved=0> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/4acbb3e2-2f0d-4624-9850-716b3cdaa83an%40googlegroups.com.
