issue with relative externals after a rename
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. Am I missing something or is this really a bug as it appears to be? Or is it maybe an issue with TortoiseSVN? Jon
Re: issue with relative externals after a rename
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? > Am I missing something or is this really a bug as it appears to be? Or is it > maybe an issue with TortoiseSVN?
Re: E195019: Redirect cycle detected for URL
On Mar 26, 2018, at 11:32, Bo Berglund wrote: > Alias /svn /var/lib/svn Remove that...
Re: issue with relative externals after a rename
On Tue, Mar 27, 2018 at 10:46 AM, Ryan Schmidt 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
Re: E195019: Redirect cycle detected for URL
On Tue, 27 Mar 2018 03:47:54 -0500, Ryan Schmidt wrote: > >On Mar 26, 2018, at 11:32, Bo Berglund wrote: > >> Alias /svn /var/lib/svn > >Remove that... > Thanks a million! This line was entered due to the howto I used: https://tecadmin.net/install-subversion-server-on-ubuntu/ Step #3 has that file content including the Alias. I did not read the user comments on that page before but the problem was already mentioned by user Bruno Romeiro with the solution given by user Sean. Shows that user feedback on howto pages like this is useful to read. I removed the line and restarted apache2 and now I do not get the error messages when doing a simple svn list command anymore. Will next go over to the master server and run the svnsync intitalize command. Hopefully this was the only problem. -- Bo Berglund Developer in Sweden
Re: Subversion 1.9.7 server on Windows, advice on setting up svnsync?
On Mon, 26 Mar 2018 08:22:16 -0500, Bo Berglund wrote: >svn: E195019: Redirect cycle detected for URL The error was caused by misconfiguration of the /etc/apache2/mods-enabled/dav_svn.conf file following the instructions in this webpage: https://tecadmin.net/install-subversion-server-on-ubuntu/ A bogus line appeared in that instruction step 3: Alias /svn /var/lib/svn <== This line must be removed Now I have synced my first of 10 repositories on the main server. It worked fine and took about 1 hour for 947 revisions. Question: - When I move forward and prepare target repositories for syncing I need to activate two hooks in each repo (pre-revprop-change and start-commit). So there will be 18 scripts to create... Can I symlink the existing hooks into the new repositories so I only need to manage one set of files? -- Bo Berglund Developer in Sweden
Re: Subversion 1.9.7 server on Windows, advice on setting up svnsync?
On 27.03.2018 22:52, Bo Berglund wrote: > When I move forward and prepare target repositories for syncing I need > to activate two hooks in each repo (pre-revprop-change and > start-commit). So there will be 18 scripts to create... > Can I symlink the existing hooks into the new repositories so I only > need to manage one set of files? Yes, of course. -- Brane
RE: issue with relative externals after a rename
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:jcor...@gmail.com] Sent: Tuesday, March 27, 2018 1:49 AM To: Jonathan Schell Cc: Subversion Users ; Ryan Schmidt Subject: Re: issue with relative externals after a rename On Tue, Mar 27, 2018 at 10:46 AM, Ryan Schmidt 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
Re: Subversion 1.9.7 server on Windows, advice on setting up svnsync?
I proceeded to sync our repositories. On the 3rd repo I get the following error at revision 210 (it contains 1290 revisions): E:\>svnsync synchronize https://home.mirrordomain.com/svn/cmp https://masterserver/svn/cmp Transmitting file data ... 8 long lines of dots ..svnsync: E120106: ra_serf: The server sent a truncated HTTP response body. The sync was interrupted so I tried restarting and it went directly to the Transmitting step as shown above. On my screen there were 8 lines of dots until the error appeared and it happened at *exactly* the same place for both the original and restarted sync command. Took a few mnutes to get there. What can this be caused by and what can I do to fix it? I am running the command on the master server (Windows Server 2016) towards an overseas server running Ubuntu 16.04 -- Bo Berglund Developer in Sweden
Re: issue with relative externals after a rename
On 28.03.2018 01:38, Jonathan Schell wrote: > 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. Because the default operative revision is HEAD and there's no such object in HEAD, yes. > 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. You need both peg and operative revisions: -r 18 ../fold1 fold1@18 -r 18 ../fold2/file1.txt@18 file1.txt The peg revision tells Subversion which object to look for and the operative revision tells it which version of that object to use. -- Brane
