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. On Tuesday, November 17, 2020 at 9:54:17 AM UTC Bruce C wrote: > 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/a497c7b5-490b-4897-a948-957c1c2433e0n%40googlegroups.com.
