I have a tree that looks like: https://svn/repo/name1/externs/normal_files_here
The folder "externs" has two external properties: ../fold1@18 fold1 ../fold2/file1.txt@18 file1.txt These folders and file exist at rev 18. The commit to add the properties to "externs" is commit 32. I then do a rename of "name1" to "name2". The externs now break, as the item they were pointing to no longer exists. So I edit the properties to: -r 18 ../fold1 fold1 -r 18 ../fold2/file1.txt file1.txt And then did an update and the file got brought in, but there was still an error on the folder. However, I just repeated the issue on a test repo and it worked fine for both the folder and the file, so maybe there's some other condition that's affecting it. Jon -----Original Message----- From: Johan Corveleyn [mailto:[email protected]] Sent: Tuesday, March 27, 2018 1:49 AM To: Jonathan Schell <[email protected]> Cc: Subversion Users <[email protected]>; Ryan Schmidt <[email protected]> Subject: Re: issue with relative externals after a rename On Tue, Mar 27, 2018 at 10:46 AM, Ryan Schmidt <[email protected]> wrote: > > On Mar 26, 2018, at 17:20, Jonathan Schell wrote: > >> I have a tree where one folder is referencing some other folders and >> documents in different parts of the tree. And those externals are pegged. >> >> So, I did a rename of the top folder of the tree. Which of course breaks >> the externals. >> >> So, I go fix the externals to be like they should, using the operative >> revision. This works for the files, but not for the folders. > > In what way does it not work? What did you do, what happened, what was > supposed to happen instead? Also, to make sure we're on the same page: Are you using the following syntax (relative and with peg revisions) in the externals property? ../../somedir@1234 somedir ../../somefile@3214 somefile Or are you using this syntax (with operative revisions instead of peg revisions)? -r1234 ../../somedir somedir -r3214 ../../somefile somefile Or perhaps a mix of both? -- Johan
