Re: Strange behavior
Am 09.08.2013 21:58, schrieb Edwin Castro: On 8/9/13 10:27 AM, John Maher wrote: And svn status returns this: C Build.bat local add, incoming add upon merge You svn add Build.bat in trunk. Later you svn add Build.bat in your branch. Subversion sees those as separate objects with individual history. I've seen this here, too. It seems to be related to a user creating a branch with the OS tools without telling SVN about it, then adding it to SVN, then porting over changes by hand, then trying to merge in more changes... To create a branch, I've learned to always do an svn copy between URLs, e.g. svn cp file:///repository/trunk file:///repository/branches/mybranch. Cheers, Ulli -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
RE: svn status --show-updates does not mark file externals with '*' when there is a new revision available on the server
Sorry, I forgot to mention the versions. Server is version 1.7.8( r1419691) on Apache httpd 2.2.23 64Bit running on a Windows 2008 Server. My client is version 1.8.1 (r1503906). Best regards, Mark Pepperl+Fuchs GmbH, Mannheim Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), Dr.-Ing. Peter Adolphs, Werner Guthier, Mehmet Hatiboglu Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Claus Michael Registergericht/Register Court: AG Mannheim HRB 4713 Wichtiger Hinweis: Diese E-Mail einschliesslich ihrer Anhaenge enthaelt vertrauliche und rechtlich geschuetzte Informationen, die nur fuer den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und loeschen Sie diese Nachricht und ihre Anhaenge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veraenderung der E-Mail ist untersagt. Der Absender haftet nicht fuer Inhalte von veraenderten E-Mails. Important Information: This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.
RE: svn 1.8 causing locks to be broken on update
Hi Felipe, Do you have access to the repository configuration at the server? Things we are most interested in is how exactly your authentication is setup. E.g. do you allow anonymous acces, and if yes in what way? Posting your server configuration (with passwords and private information changed) would really help. I don’t think the serf debug log is really giving much more information here, as there are (as far as I can tell) no requests that fail. The default server side logging (if not disabled) provides most likely more than enough information to look into this. Last night (EU time) we spend some time with different scenarios in an attempt to reproduce your issue, but we were unable to. Bert From: Felipe Alvarez [mailto:felipe.alva...@gmail.com] Sent: donderdag 15 augustus 2013 04:29 To: Johan Corveleyn; William Smith; philip.mar...@wandisco.com Cc: Hiroharu Tamaru; Users Subversion Apache Subject: Re: svn 1.8 causing locks to be broken on update As of 1.8 SVN only uses the serf library for http communication, and no longer the neon library (before 1.8, both were part of svn, but neon was the default library). Unfortunately there is no runtime-switch (yet) to enable debug output with svn+serf. There is already an open enhancement request for this [1]. You can enable debug logging with serf by rebuilding (see [2]). With your combined input, this issue really starts to look like a serf-related issue. - Succeeds with file:// file:///\\ - Fails with http(s), but only with 1.8 clients, not with older clients. To double check that it's serf-related, perhaps one of you could try with 1.7+serf, and see if that fails as well. You can enable serf with 1.7 by specifying http-library=serf in the servers configuration file, or by passing --config-option servers:global:http-library=serf on the command line. Perhaps it's time to open an issue in the issue tracker for this. Subversion client 1.7 using serf cause the lock to break! But it does not break when using neon (default) ---8--- C:\tmpsvn --username will --password will co http://svntest.freshcomp.com.au/svn/repos --config-option servers:global:http-library=serf wc Awc\Trunk Awc\Trunk\Lettus Awc\Trunk\Lettus\lbin Awc\Trunk\Lettus\lbin\file2.txt Awc\Trunk\Lettus\lbin\test.txt Awc\Trunk\Lettus\lbin\file1.txt Checked out revision 4. C:\tmpcd wc\Trunk\Lettus\lbin C:\tmp\wc\Trunk\Lettus\lbindir Directory of C:\tmp\wc\Trunk\Lettus\lbin 15/08/2013 12:07 PMDIR . 15/08/2013 12:07 PMDIR .. 13/08/2013 01:14 PM 6 file1.txt 13/08/2013 05:01 PM 5 file2.txt 13/08/2013 05:35 PM 6 test.txt 3 File(s) 17 bytes 2 Dir(s) 89,690,247,168 bytes free C:\tmp\wc\Trunk\Lettus\lbinsvn lock test.txt --config-option servers:global:http-library=serf 'test.txt' locked by user 'will'. C:\tmp\wc\Trunk\Lettus\lbinsvn st --config-option servers:global:http-library=serf K test.txt C:\tmp\wc\Trunk\Lettus\lbincd .. C:\tmp\wc\Trunk\Lettussvn up --config-option servers:global:http-library=serf Updating '.': At revision 4. C:\tmp\wc\Trunk\Lettuscd .. C:\tmp\wc\Trunksvn up --config-option servers:global:http-library=serf Updating '.': At revision 4. C:\tmp\wc\Trunkcd .. C:\tmp\wcsvn up --config-option servers:global:http-library=serf Updating '.': UB Trunk\Lettus\lbin\test.txt Updated to revision 4. C:\tmp\wcsvn st --config-option servers:global:http-library=serf C:\tmp\wc ---8--- -- Felipe
Re: svn 1.8 causing locks to be broken on update
On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn jcor...@gmail.com wrote: On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez felipe.alva...@gmail.com wrote: I have the same issue. It happens when I run 1.8.1 windows client with 1.6.9 https repository sever. I haven't tried so many combinations ATM, but here are some observations: 1.8.1 client run with 1.6.9 https:// repo server gives this issue. 1.8.1 client run with 1.6.9 generated file:/// repositories are OK. 1.8.1 client run with 1.7.6 generated file:/// repositories are OK. 1.7.6 client run with 1.6.9 https:// repo server is OK. Whether the WC is freshly checked out by 1.8.1 client, or upgraded from 1.7.6 checked out WC did not change the results. How's the case for the original poster? Do we see something in common? # I'm reading this ML through the archives. -- Hiroharu Hi Hiroharu You are indeed correct. We have done a very similar experiment here, too. We tried all of the above scenarios you gave. But our older client was 1.6.15, and we did not use https, we used http (apache 2.2) With the help of my colleague we have done some testing with svn 1.8.1 (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client. Using the file:/// method in all cases works fine (locks NOT broken). All other methods also work fine, including http. Of the tests we made, the one which breaks the locks is: client 1.8.1; repository made with svn 1.6.15; protocol HTTP (apache 2.2). One method that we have not yet tried is: client 1.8.1; repo with svn client 1.8.1; protocol HTTP How do I enabled debugging in .subversion/config or .subversion/servers? It used to be something like neon-debug but that's no longer available since 1.8.1 (or 1.8) As of 1.8 SVN only uses the serf library for http communication, and no longer the neon library (before 1.8, both were part of svn, but neon was the default library). Unfortunately there is no runtime-switch (yet) to enable debug output with svn+serf. There is already an open enhancement request for this [1]. You can enable debug logging with serf by rebuilding (see [2]). A FYI to Johan: note that there are two levels of abstraction here: - serf: the http library that's now used instead of neon: implements the http protocol and sends/receives bytes over the network - ra_serf: the subversion ra module that uses serf to communicate with a mod_dav_svn module in an apache server via XML request/reply messaging If there's an issue that looks like missing or corrupted data, connection or authentication problems then we look to the serf library. The logging you refer to is then a good way to start gathering info on what's going wrong. However in this case it seems that the communication itself is ok, but there's a potential issue in how ra_serf drives the communication (i.e. the content of the xml requests). Serf logging will not help here as it's a level too deep. A simple wireshark trace can help, once the exact reproduction recipe is known. (serf can also log request and reply output, even with https, but it's easier to use wireshark) Lieven With your combined input, this issue really starts to look like a serf-related issue. - Succeeds with file:// - Fails with http(s), but only with 1.8 clients, not with older clients. To double check that it's serf-related, perhaps one of you could try with 1.7+serf, and see if that fails as well. You can enable serf with 1.7 by specifying http-library=serf in the servers configuration file, or by passing --config-option servers:global:http-library=serf on the command line. Perhaps it's time to open an issue in the issue tracker for this. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4407 (Provide serf equivalent of neon-debug-mask) [2] http://svn.haxx.se/users/archive-2013-07/0344.shtml -- Johan
Re: Suggestion to change the name Subversion
On 13.08.2013 02:03, Nico Kadel-Garcia wrote: No one else remember the old Satan monitoring toolkit, that had an option to change the displayed name and icon to Santa? The name Subversion has enough positive reputation that changing it, just to avoid NSA style monitoring, seems very destabilizing to a popular project. Let's not change it. I'm all for filling up NSA's databases with subversive connotations. Helps finance open source (Hadoop, don't y'know). :) -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Geoff Field geoff_fi...@aapl.com.au writes: I've just commented out the AuthzSVNAccessFile line and have done the following: C:\SVN_Testsvn ci test6.txt --message test 1.8.1 checkin Adding test6.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date svn: E175005: File 'test6.txt' already exists 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1 201 439 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] HEAD /Subversion/Playground/trunk/test6.txt HTTP/1.1 401 - 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 401 580 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 204 - That still shows 401 unauthorized which is odd if you are not using Authz. Do you have some other authz beyond AuthzSVNAccessFile? The 1.2.3 client simply shows that with neon we don't send HEAD. Again, the error log did not change. You may get more information if you add LogLevel debug -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: svn 1.8 causing locks to be broken on update
Felipe Alvarez felipe.alva...@gmail.com writes: I'm using a 1.8.x client and a 1.6.x server and I can't reproduce it. I tried this svnadmin create repo --compatible-version 1.6 svn co http://localhost:/obj/repo wc svn mkdir --parents wc/A/B/C touch wc/A/B/C/f svn add wc/A/B/C/f svn ci -mm wc svn up wc svn lock wc/A/B/C/f cd wc/A svn up cd .. svn up cd .. svn st wc and the final status shows wc/A/B/C/f still locked. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* Hi Philip Pardon my ignorance. We are using an authentic 1.6.15 client, not a 1.8.1 in 1.6 mode (If I am interpreting your --compatible-version option correctly). Further, we are using Apache 2.2 with the following config http://pastebin.com/ZefLnHA9 We followed the exact same steps as you have, but not localhost, we used a remote host. Should it matter? I have determined that the the lock gets broken when I use a 1.6.16 server but it is not broken when I use a 1.6.17 server. It was fixed by r1124173. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: svn 1.8 causing locks to be broken on update
-Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: donderdag 15 augustus 2013 11:41 To: Felipe Alvarez Cc: Hiroharu Tamaru; Users Subversion Apache; Johan Corveleyn; William Smith Subject: Re: svn 1.8 causing locks to be broken on update Felipe Alvarez felipe.alva...@gmail.com writes: I'm using a 1.8.x client and a 1.6.x server and I can't reproduce it. I tried this svnadmin create repo --compatible-version 1.6 svn co http://localhost:/obj/repo wc svn mkdir --parents wc/A/B/C touch wc/A/B/C/f svn add wc/A/B/C/f svn ci -mm wc svn up wc svn lock wc/A/B/C/f cd wc/A svn up cd .. svn up cd .. svn st wc and the final status shows wc/A/B/C/f still locked. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* Hi Philip Pardon my ignorance. We are using an authentic 1.6.15 client, not a 1.8.1 in 1.6 mode (If I am interpreting your --compatible-version option correctly). Further, we are using Apache 2.2 with the following config http://pastebin.com/ZefLnHA9 We followed the exact same steps as you have, but not localhost, we used a remote host. Should it matter? I have determined that the the lock gets broken when I use a 1.6.16 server but it is not broken when I use a 1.6.17 server. It was fixed by r1124173. Ah, good catch: [[ r1104309 | cmpilato | 2011-05-17 17:02:05 +0200 (di, 17 mei 2011) | 20 lines With rhuijben, avoid transmitting entry props for unmodified, locked files when the client-provided lock token matches what is stored in the repository. This fixes issue #3525 (Locked file which is scheduled for delete causes tree conflict) and issue #3471 (svn up touches file w/ lock svn:keywords property). NOTE: There is a remaining 3525-related test that is still failing (update_tests.py 53), but that's because of out-of-date expectations in the WC-NG world. (That will be fixed in a subsequent revision.) * subversion/libsvn_repos/reporter.c (update_entry): Return early not only when there's not a provided lock token, but also when there's a provided lock token that matches what's in the repository. * subversion/tests/cmdline/lock_tests.py (update_locked_deleted): Remove @XFail decorator. * subversion/tests/cmdline/update_tests.py (update_with_file_lock_and_keywords_property_set): Remove @XFail decorator. ]] A group effort on 2011's SvnDay Hackathon :) Bert
Re: svn 1.8 causing locks to be broken on update
On Thu, Aug 15, 2013 at 12:12 PM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: donderdag 15 augustus 2013 11:41 To: Felipe Alvarez Cc: Hiroharu Tamaru; Users Subversion Apache; Johan Corveleyn; William Smith Subject: Re: svn 1.8 causing locks to be broken on update Felipe Alvarez felipe.alva...@gmail.com writes: I'm using a 1.8.x client and a 1.6.x server and I can't reproduce it. I tried this svnadmin create repo --compatible-version 1.6 svn co http://localhost:/obj/repo wc svn mkdir --parents wc/A/B/C touch wc/A/B/C/f svn add wc/A/B/C/f svn ci -mm wc svn up wc svn lock wc/A/B/C/f cd wc/A svn up cd .. svn up cd .. svn st wc and the final status shows wc/A/B/C/f still locked. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* Hi Philip Pardon my ignorance. We are using an authentic 1.6.15 client, not a 1.8.1 in 1.6 mode (If I am interpreting your --compatible-version option correctly). Further, we are using Apache 2.2 with the following config http://pastebin.com/ZefLnHA9 We followed the exact same steps as you have, but not localhost, we used a remote host. Should it matter? I have determined that the the lock gets broken when I use a 1.6.16 server but it is not broken when I use a 1.6.17 server. It was fixed by r1124173. Ah, good catch: [[ r1104309 | cmpilato | 2011-05-17 17:02:05 +0200 (di, 17 mei 2011) | 20 lines With rhuijben, avoid transmitting entry props for unmodified, locked files when the client-provided lock token matches what is stored in the repository. This fixes issue #3525 (Locked file which is scheduled for delete causes tree conflict) and issue #3471 (svn up touches file w/ lock svn:keywords property). NOTE: There is a remaining 3525-related test that is still failing (update_tests.py 53), but that's because of out-of-date expectations in the WC-NG world. (That will be fixed in a subsequent revision.) * subversion/libsvn_repos/reporter.c (update_entry): Return early not only when there's not a provided lock token, but also when there's a provided lock token that matches what's in the repository. * subversion/tests/cmdline/lock_tests.py (update_locked_deleted): Remove @XFail decorator. * subversion/tests/cmdline/update_tests.py (update_with_file_lock_and_keywords_property_set): Remove @XFail decorator. ]] A group effort on 2011's SvnDay Hackathon :) Bert Great! I remember that series of lock-related discussions / fixes. Now, playing user's advocate: is there still something useful to do here? I.e. apparently ra_neon worked fine with the broken servers. Should ra_serf also be able to handle this, so 1.8 clients can still work fine with servers 1.6.17? -- Johan
Re: Suggestion to change the name Subversion
On Mon, Aug 12, 2013 at 10:57 PM, Glenn Holmer ghol...@weycogroup.com wrote: On 08/12/2013 03:51 PM, Greg Stein wrote: Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Great story, thanks! And if you want to know how to pronounce Subversion: http://subversion.apache.org/faq.html#pronounce :-) -- Johan
Re: svn 1.8 causing locks to be broken on update
On Thu, Aug 15, 2013 at 6:19 PM, Bert Huijben b...@qqmail.nl wrote: Hi Felipe, Do you have access to the repository configuration at the server? Things we are most interested in is how exactly your authentication is setup. E.g. do you allow anonymous acces, and if yes in what way? Posting your server configuration (with passwords and private information changed) would really help. I don’t think the serf debug log is really giving much more information here, as there are (as far as I can tell) no requests that fail. The default server side logging (if not disabled) provides most likely more than enough information to look into this. Last night (EU time) we spend some time with different scenarios in an attempt to reproduce your issue, but we were unable to. Bert Hi Bert. I do have access to the server. I posted the HTTP config here http://pastebin.com/ZefLnHA9 - we do not allow anonymous access - auth is handles by htpasswd valid-user (also use 'authz' to hide some directories from some users, but I do not believe this is the case here) I'm outputing the access_log of the virtualhost which runs SVN server (apache). I hope I'm not spamming. I thought it was too small to paste on pastebin... ps. the 'error_log' was 0 bytes This is output from a 1.6.15 client and 1.6.15 server. Locks are not broken ---BEGIN--- cat access_log_svntest_1.6.15 192.168.0.20 - - [15/Aug/2013:21:21:37 +1000] OPTIONS / HTTP/1.1 200 - - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - - [15/Aug/2013:21:21:47 +1000] OPTIONS / HTTP/1.1 200 - - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - - [15/Aug/2013:21:22:01 +1000] OPTIONS /svn/repos HTTP/1.1 401 491 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] OPTIONS /svn/repos HTTP/1.1 200 189 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] PROPFIND /svn/repos HTTP/1.1 207 649 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] PROPFIND /svn/repos/!svn/vcc/default HTTP/1.1 207 400 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:04 +1000] PROPFIND /svn/repos/!svn/bln/4 HTTP/1.1 207 451 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos HTTP/1.1 207 649 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/vcc/default HTTP/1.1 207 400 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/bln/4 HTTP/1.1 207 451 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos HTTP/1.1 207 649 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/vcc/default HTTP/1.1 207 451 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/bc/4 HTTP/1.1 207 659 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - - [15/Aug/2013:21:22:06 +1000] OPTIONS /svn/repos HTTP/1.1 401 491 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] OPTIONS /svn/repos HTTP/1.1 200 189 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos HTTP/1.1 207 649 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos HTTP/1.1 207 649 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/vcc/default HTTP/1.1 207 400 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/bln/4 HTTP/1.1 207 451 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos HTTP/1.1 207 649 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/vcc/default HTTP/1.1 207 400 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] PROPFIND /svn/repos/!svn/bln/4 HTTP/1.1 207 451 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:06 +1000] REPORT /svn/repos/!svn/vcc/default HTTP/1.1 200 3946 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - - [15/Aug/2013:21:22:51 +1000] OPTIONS /svn/repos/Trunk/Lettus/lbin HTTP/1.1 401 491 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] OPTIONS /svn/repos/Trunk/Lettus/lbin HTTP/1.1 200 189 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] PROPFIND /svn/repos/Trunk/Lettus/lbin HTTP/1.1 207 712 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe [15/Aug/2013:21:22:51 +1000] PROPFIND /svn/repos/Trunk/Lettus/lbin/file1.txt HTTP/1.1 207 698 - SVN/1.6.15 (r1038135) neon/0.25.5 192.168.0.20 - felipe
Re: svn 1.8 causing locks to be broken on update
Johan Corveleyn jcor...@gmail.com writes: Now, playing user's advocate: is there still something useful to do here? I.e. apparently ra_neon worked fine with the broken servers. Should ra_serf also be able to handle this, so 1.8 clients can still work fine with servers 1.6.17? It appears to be related to a path handling bug in code that is supposed to handle old servers, the obvious fix makes the problem worse. I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4412 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Suggestion to change the name Subversion
On 08/15/2013 06:18 AM, Johan Corveleyn wrote: On Mon, Aug 12, 2013 at 10:57 PM, Glenn Holmer ghol...@weycogroup.com wrote: On 08/12/2013 03:51 PM, Greg Stein wrote: Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Great story, thanks! And if you want to know how to pronounce Subversion: http://subversion.apache.org/faq.html#pronounce Hahaha, I still have copies of Linus saying the corresponding thing in English and Swedish. -- Glenn Holmer Weyco Group, Inc. phone: 414-908-1809 fax: 414-908-1601
Re: How to change paths on an external file without a full update --depth infinity?
Once you copy, you break the link. If you were to make a change to the copy, no one else would then see it. No one else would see it with externals either, except that you wrote a custom tool to analyze the externals, see if a newer revision of the original exists, and show that to the user. If you can do that with externals, you can do that with copies too. (Use svn log --stop-on-copy to find out where the copy came from, then see if there are newer revisions of that.) The challenge I then see on this is one of finding all instances of foo.c. If you have foo.c copied/forked fifty times to different projects, each of which has branched a couple of times, how do you programmatically find all different instances of foo.c (to let a developer choose which may be most appropriate?) If you have good ideas, I'm very open to listening. Also if you have to projects that both want foo.c and both have valid changes to make to the file, how does that get managed when they are copies? Its a trivial implementation when it is implemented as a file external. We also have instances where we purposely want multiple copies of the same exact file within the same project. We can effectively manage this through file externals to a structured datastore (AKA a set of folders within a repo). Regardless of where and how a team decides to structure their project, all files are neatly organized in this one section of the repo (that is considered taboo to directly interact with). The ability to have a specific file having many copies of itself and not care about its position within the repository is a powerful feature. I understand this may diverge a bit from SVN's core thoughts on CM, but if SVN can support odd variations to its use, it becomes an even more indispensable building block. Diversity in approaches is good. From a feature perspective, externals are a very appropriate method to accomplish this (really a CM implementation of symlinks). If we're saying that externals from an implementation standpoint are not quite appropriate at this time, I get that argument. What is the general consensus as to where externals are on the roadmap? I may not convince the team that externals are really really useful (even if abused) in this application, but I'm hoping that the team does appreciate the general usefulness of externals and keeps maturing the feature. Thanks Dan
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 10:12 AM, dlel...@rockwellcollins.com wrote: Once you copy, you break the link. If you were to make a change to the copy, no one else would then see it. No one else would see it with externals either, except that you wrote a custom tool to analyze the externals, see if a newer revision of the original exists, and show that to the user. If you can do that with externals, you can do that with copies too. (Use svn log --stop-on-copy to find out where the copy came from, then see if there are newer revisions of that.) The challenge I then see on this is one of finding all instances of foo.c. If you have foo.c copied/forked fifty times to different projects, each of which has branched a couple of times, how do you programmatically find all different instances of foo.c (to let a developer choose which may be most appropriate?) If you have good ideas, I'm very open to listening. There is no difference in that question than finding where the 'future' copies of a pegged external target went. You can only do either if you have a convention for a canonical path. Also if you have to projects that both want foo.c and both have valid changes to make to the file, how does that get managed when they are copies? Its a trivial implementation when it is implemented as a file external. How so? I assume you also have to handle cases either way: where both projects want the same change and where both projects need different changes - where typical svn users would have branches/tags to distinguish them. But regardless of how you identify the target file, there shouldn't be any effective difference between copying a version into your directory or using a file external as long as you don't modify it in place and commit it back - something your external tool could track. We also have instances where we purposely want multiple copies of the same exact file within the same project. We can effectively manage this through file externals to a structured datastore (AKA a set of folders within a repo). Regardless of where and how a team decides to structure their project, all files are neatly organized in this one section of the repo (that is considered taboo to directly interact with). The ability to have a specific file having many copies of itself and not care about its position within the repository is a powerful feature. I understand this may diverge a bit from SVN's core thoughts on CM, but if SVN can support odd variations to its use, it becomes an even more indispensable building block. Diversity in approaches is good. Again, you get the history in a copy. You can tell if they are the same. Or, on unix-like systems you can use symlinks to a canonical copy within the project. From a feature perspective, externals are a very appropriate method to accomplish this (really a CM implementation of symlinks). If we're saying that externals from an implementation standpoint are not quite appropriate at this time, I get that argument. What is the general consensus as to where externals are on the roadmap? I agree that externals are very useful, but most projects would use them at subdirectory levels for component libraries where they work nicely, not for thousands of individual file targets. Is there really no natural grouping - perhaps even of sets of combinations that have been tested together that you could usefully group in release-tagged directories? I may not convince the team that externals are really really useful (even if abused) in this application, but I'm hoping that the team does appreciate the general usefulness of externals and keeps maturing the feature. Please make the distinction between file externals - which are sort of an exception with special handling, and normal externals. Subversion uses directories as a natural sort of project container - which, not surprisingly fits the model of most things you want to manage on computers, and some reasonable number of directory-level externals 'just work' without special considerations. I'm not against better performance, of course, but it makes sense to me to make pragmatic design decisions for the same reasons you might avoid throwing millions of files in one flat directory even in a non-versioned scenario. Theoretically, you should be able to do that, but in practice it isn't going to perform as well as something with better structure. -- Les Mikesell lesmikes...@gmail.com
svnserve 1.8 freezes
Hi, all! I wanted to check if anyone else experienced similar issue like the on I have. I have svn server running on Windows XP as service (using svnserve.exe). Everything was working fine until I switched server from 1.7 to 1.8. From that moment, every few days, SVN server would freeze eating up all cpu it can (50% on dual core system). Note that I upgraded repository after upgrading svn software. I created full dump of frozen svnserver.exe (70MB in size) to help developers resolve the issue. Has anyone else had this kind of problem with 1.8 server? Regards, Aleksa
Re: Suggestion to change the name Subversion
On 8/12/2013 8:03 PM, Nico Kadel-Garcia wrote: No one else remember the old Satan monitoring toolkit, that had an option to change the displayed name and icon to Santa? The name Subversion has enough positive reputation that changing it, just to avoid NSA style monitoring, seems very destabilizing to a popular project. Let's not change it. We get around this whole issue with our users by either always saying Subversion instead of subversion so that it's clear we're talking about a proper noun instead of a verb. Or by just using SVN.
Re: Suggestion to change the name Subversion
On 2013/08/12 5:25 PM, Mauricio Tavares wrote: On Mon, Aug 12, 2013 at 4:57 PM, Glenn Holmer ghol...@weycogroup.com wrote: On 08/12/2013 03:51 PM, Greg Stein wrote: Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Great story, thanks! Agreed. On the name change topic, I had a professor who would greet people with heaveno because he believed the traditional greeting had satanic connotations. His attempts to make us use that did not go very far... http://lyrics.wikia.com/Andrew_Rannells:Hello! http://lyrics.wikia.com/Andrew_Rannells:Hello%21 :) --Roman ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Suggestion to change the name Subversion
On Thu, Aug 15, 2013 at 12:23:35PM -0400, Thomas Harold wrote: We get around this whole issue with our users by either always saying Subversion instead of subversion so that it's clear we're talking about a proper noun instead of a verb. Or by just using SVN. Ah, the Secret Vigilante Network! Very suspicious.
Re: How to change paths on an external file without a full update --depth infinity?
The challenge I then see on this is one of finding all instances of foo.c. If you have foo.c copied/forked fifty times to different projects, each of which has branched a couple of times, how do you programmatically find all different instances of foo.c (to let a developer choose which may be most appropriate?) If you have good ideas, I'm very open to listening. There is no difference in that question than finding where the 'future' copies of a pegged external target went. You can only do either if you have a convention for a canonical path. true (I believe). Also if you have to projects that both want foo.c and both have valid changes to make to the file, how does that get managed when they are copies? Its a trivial implementation when it is implemented as a file external. How so? I assume you also have to handle cases either way: where both projects want the same change and where both projects need different changes - where typical svn users would have branches/tags to distinguish them. But regardless of how you identify the target file, there shouldn't be any effective difference between copying a version into your directory or using a file external as long as you don't modify it in place and commit it back - something your external tool could track. We do want to modify in place. Copying back creates an additional step that is already managed quite well by SVN with externals. I don't want to duplicate something that already exists (I'll mess it up). There was some discussion on another thread about advancing a peg revision of an external when an external is committed. This would be a neat feature, though I completely understand why it would not be incorporated. We do this behind the scenes right now with very little work (post-commit script in TSVN gives us knowledge of what a user committed). We also have instances where we purposely want multiple copies of the same exact file within the same project. We can effectively manage this through file externals to a structured datastore (AKA a set of folders within a repo). Regardless of where and how a team decides to structure their project, all files are neatly organized in this one section of the repo (that is considered taboo to directly interact with). The abilityto have a specific file having many copies of itself and not care about its position within the repository is a powerful feature. I understand this may diverge a bit from SVN's core thoughts on CM, but if SVN can support odd variations to its use, it becomes an even more indispensable building block. Diversity in approaches is good. Again, you get the history in a copy. You can tell if they are the same. Or, on unix-like systems you can use symlinks to a canonical copy within the project. We're not a unix-like system but that is what would work great (with the exception that you can't revision control symlinks, right?) From a feature perspective, externals are a very appropriate method to accomplish this (really a CM implementation of symlinks). If we're saying that externals from an implementation standpoint are not quite appropriate at this time, I get that argument. What is the general consensus as to where externals are on the roadmap? I agree that externals are very useful, but most projects would use them at subdirectory levels for component libraries where they work nicely, not for thousands of individual file targets. Is there really no natural grouping - perhaps even of sets of combinations that have been tested together that you could usefully group in release-tagged directories? The whole discovery we found is that most of our reuse occurred in unplanned ways (I'd imagine if you took two linux distros and compare files which changed and didn't change, it would be a huge collection of random files that aren't easily abstracted out. You might be able to do it once, but as each new distribution branches out, the commonality between each of them becomes impossible to form groupings on. ...'just work' without special considerations. I'm not against better performance, of course, but it makes sense to me to make pragmatic design decisions for the same reasons you might avoid throwing millions of files in one flat directory even in a non-versioned scenario. Theoretically, you should be able to do that, but in practice it isn't going to perform as well as something with better structure. I'm not sure what a reasonable number of external files per folder is, but I'd think it'd be similar to a reasonable number of regular files would be. Two million is nuts, but 50 seems reasonable. The issue is that I'm currently forced to deal with not just the current directory, but the recursion on all nested directories (--depth infinity). If, as the subject of this thread requests, we could perform work on the directory at hand at not the
svn merge --reintegrate - quick question
Hi All We have a situation where a few folks dont use --reintegrate option when performing svn merge, while others do. What's 1- the consequence of not using --reintegrate option; can the feature branch continue to svn merge to trunk the 2nd time and thereafter ? 2- the impact on those feature branches that do use --reintegrate option; from what we read in the manual, that one cannot use this feature branches anymore. Thanks Sincerely
Re: svn 1.8 causing locks to be broken on update
On Thu, Aug 15, 2013 at 10:30 AM, Lieven Govaerts lieven.govae...@gmail.com wrote: On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn jcor...@gmail.com wrote: On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez felipe.alva...@gmail.com wrote: ... How do I enabled debugging in .subversion/config or .subversion/servers? It used to be something like neon-debug but that's no longer available since 1.8.1 (or 1.8) As of 1.8 SVN only uses the serf library for http communication, and no longer the neon library (before 1.8, both were part of svn, but neon was the default library). Unfortunately there is no runtime-switch (yet) to enable debug output with svn+serf. There is already an open enhancement request for this [1]. You can enable debug logging with serf by rebuilding (see [2]). A FYI to Johan: note that there are two levels of abstraction here: - serf: the http library that's now used instead of neon: implements the http protocol and sends/receives bytes over the network - ra_serf: the subversion ra module that uses serf to communicate with a mod_dav_svn module in an apache server via XML request/reply messaging If there's an issue that looks like missing or corrupted data, connection or authentication problems then we look to the serf library. The logging you refer to is then a good way to start gathering info on what's going wrong. However in this case it seems that the communication itself is ok, but there's a potential issue in how ra_serf drives the communication (i.e. the content of the xml requests). Serf logging will not help here as it's a level too deep. A simple wireshark trace can help, once the exact reproduction recipe is known. (serf can also log request and reply output, even with https, but it's easier to use wireshark) Lieven Ah yes, thanks. I will keep that in mind. -- Johan
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 12:39 PM, dlel...@rockwellcollins.com wrote: But regardless of how you identify the target file, there shouldn't be any effective difference between copying a version into your directory or using a file external as long as you don't modify it in place and commit it back - something your external tool could track. We do want to modify in place. Copying back creates an additionalstep that is already managed quite well by SVN with externals. I've never done that with a file external - where does the commit go? It commits a new revision of what the file external pointed to - pretty handy. If you are pegged, it will not automagically update your pegged revision (as I'd expect), so unless you are on the HEAD or update your peg to what just committed, an update will revert your WC back to the pegged version. Again, you get the history in a copy. You can tell if they are the same. Or, on unix-like systems you can use symlinks to a canonical copy within the project. We're not a unix-like system but that is what would work great (with the exception that you can't revision control symlinks, right?) I think so, but the links and the target would be versioned independently which might complicate your tracking. Yes, it would complicate things quite a bit and introduce areas for defects to get introduced. The whole discovery we found is that most of our reuse occurred inunplanned ways (I'd imagine if you took two linux distros and compare files which changed and didn't change, it would be a huge collection of random files that aren't easily abstracted out. You might be able to do it once, but as each new distribution branches out, the commonality between each of them becomes impossible to form groupings on. I was thinking of just adding an extra layer of grouping management that would be versioned and able to be duplicated as much as necessary. Suppose you made 10 directories and copied 100 files into each with tagged versions of these directories for every combination you need to access. Normally there would be natural groupings where there is a common manager making decisions, etc., but for the moment just consider it for performance. Within the repository, the copies are cheap like symlinks - you could have a large number of pre-arranged tagged choices. Then your top level project becomes 10 directory-level externals instead of 1000 file externals. With more complexity comes more bugs and process missteps. We're really striving to keep things as simple as possible. We're fundamentally accepting of update times going from 2 seconds to 2 minutes. Its harder when 2 minutes becomes 20 minutes. I'm not sure what a reasonable number of external files per folder is, but I'd think it'd be similar to a reasonable number of regular files would be. Two million is nuts, but 50 seems reasonable. Think of this in terms of client-server activity. With directory level externals, the client can ask the server if anything under the directory has newer revisions in one exchange and if it hasn't, you are done. So what's reasonable is the amount of activity you want to wait for. The whole discussion has centered on an attempted work around for the connection caching that doesn't currently occur for externals. If that can happen, I think we'd be very content. We're accepting of some performance issues. There was an XKCD a while ago that talked about how much time a task takes, how many times you do it and how much waste is created over a year. It was interesting (even if obvious if you thought about it). I think with connection caching we'd hit the sweet spot and working further would result in diminishing returns. This thread is an attempt a hopefully short-term work around this limitation. Usually I'd consider the 'human' side of organization first, so if you can come up with any groupings that could be done as copies into tagged directories you might want to arrange them by the people/groups who make the choices - and then the performance win would just be an extra bonus. That's just it, we can't find (let alone maintain over time) any consistent groupings by function. Trying to create groupings other ways could confuse the developers, or if we try and hide the fact that we have an optimized backend of sorts, we then have to write more tool software (we don't like writing tools, we like writing embedded software). In the end, revision controlled symlinks are the best answer and file externals appear to be very close. And we're oh so close with file externals right now. Thanks Dan
[BUG] -std=c90 passed to non-GCC compilers
I am building Subversion 1.8.1 on Solaris 10 on AMD64, using the vendor compiler. All of the compile lines produce a warning from the compiler: /bin/bash /tmp/subversion-build/libtool --tag=CC --silent --mode=compile cc -std=c90 -D__EXTENSIONS__ -D_REENTRANT-DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS [...] cc: Warning: illegal option -d=c90 The -std=c90 flag appears to be added by the SVN_CC_MODE_SETUP() macro in build/ac-macros/compiler.m4. This then uses SVN_CFLAGS_ADD_IFELSE(), which checks to see if the compiler accepts a specified flag. This macro assumes that the compiler will throw an error if it doesn't recognize a flag, which unfortunately does not hold true in the case of the Sun compiler and this -std= flag. According to cc -flags, -s is Strip symbol table from the executable file. The cc(1) man page states cc recognizes -a, -e, -r, -t, -u, and -z and passes these options and their arguments to ld. cc also passes any unrecognized options to ld with a warning. Perhaps the macro should check the value of $GCC before testing this flag? --Daniel P.S.: Please Cc: any replies, as I am not subscribed to this list. -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman.
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 2:03 PM, dlel...@rockwellcollins.com wrote: With more complexity comes more bugs and process missteps. We're really striving to keep things as simple as possible. We're fundamentally accepting of update times going from 2 seconds to 2 minutes. Its harder when 2 minutes becomes 20 minutes. Are your build systems on the other side of the world from the repository? The quick fix might be to reduce the latency one way or another (move one of the pieces, use the wandisco distributed repo approach, etc?) or automate with something like jenkins so you don't have a person waiting. -- Les Mikesell lesmikes...@gmail.com
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 2:03 PM, dlel...@rockwellcollins.com wrote: With more complexity comes more bugs and process missteps. We're really striving to keep things as simple as possible. We're fundamentally accepting of update times going from 2 seconds to 2 minutes. Its harder when 2 minutes becomes 20 minutes. Are your build systems on the other side of the world from the repository? The quick fix might be to reduce the latency one way or another (move one of the pieces, use the wandisco distributed repo approach, etc?) or automate with something like jenkins so you don't have a person waiting. Yes, and that's a big contributor. Co-location helps significantly, but isn't an option in our case. I'll take a look at your suggestions. Thanks dan
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 2:24 PM, dlel...@rockwellcollins.com wrote: With more complexity comes more bugs and process missteps. We're really striving to keep things as simple as possible. We're fundamentally accepting of update times going from 2 seconds to 2 minutes. Its harder when 2 minutes becomes 20 minutes. Are your build systems on the other side of the world from the repository? The quick fix might be to reduce the latency one way or another (move one of the pieces, use the wandisco distributed repo approach, etc?) or automate with something like jenkins so you don't have a person waiting. Yes, and that's a big contributor. Co-location helps significantly, but isn't an option in our case. I'll take a look at your suggestions. Depending on your platform and tools, there are times when it works better to have a remote display to a machine on a network where the real work happens than to copy everything locally. And if you can automate with Jenkins, you don't really even need the display for the build, although you do have to somehow commit your changes to subversion. -- Les Mikesell lesmikes...@gmail.com
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 9:03 PM, dlel...@rockwellcollins.com wrote: ... The whole discussion has centered on an attempted work around for the connection caching that doesn't currently occur for externals. If that can happen, I think we'd be very content. We're accepting of some performance issues. There was an XKCD a while ago that talked about how much time a task takes, how many times you do it and how much waste is created over a year. It was interesting (even if obvious if you thought about it). I think with connection caching we'd hit the sweet spot and working further would result in diminishing returns. This thread is an attempt a hopefully short-term work around this limitation. As you've read in the responses by Ben Reser and Ivan Zhakov earlier in this thread, the ra-session-reuse (connection caching) is work in progress. That might take some time before it ends up in a final release (if it's slated for 1.9, that's at least half a year away). Have you considered setting up something like write-through proxying[1], where you set up local read-only mirrors of your central svn repository (which transparently sent through write requests to the master)? That might significantly reduce latency for those read operations, and might be good enough to make things workable. [1] http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy -- Johan
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 2:03 PM, dlel...@rockwellcollins.com wrote: We do want to modify in place. Copying back creates an additionalstep that is already managed quite well by SVN with externals. I've never done that with a file external - where does the commit go? It commits a new revision of what the file external pointed to - pretty handy. If you are pegged, it will not automagically update your pegged revision (as I'd expect), so unless you are on the HEAD or update your peg to what just committed, an update will revert your WC back to the pegged version. I'd actually expect it to be pretty confusing if you had multiple people committing changes based from different back-rev pegged references anywhere near the same time frame. Does your external 'notify about new versions' tool help with that? Don't you get conflicting changes that you'd want branches to help isolate? -- Les Mikesell lesmikes...@gmail.com
Re: [BUG] -std=c90 passed to non-GCC compilers
On 15.08.2013 21:08, Daniel Richard G. wrote: I am building Subversion 1.8.1 on Solaris 10 on AMD64, using the vendor compiler. All of the compile lines produce a warning from the compiler: /bin/bash /tmp/subversion-build/libtool --tag=CC --silent --mode=compile cc -std=c90 -D__EXTENSIONS__ -D_REENTRANT-DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS [...] cc: Warning: illegal option -d=c90 The -std=c90 flag appears to be added by the SVN_CC_MODE_SETUP() macro in build/ac-macros/compiler.m4. This then uses SVN_CFLAGS_ADD_IFELSE(), which checks to see if the compiler accepts a specified flag. This macro assumes that the compiler will throw an error if it doesn't recognize a flag, Indeed it does so assume ... which unfortunately does not hold true in the case of the Sun compiler and this -std= flag. According to cc -flags, -s is Strip symbol table from the executable file. The cc(1) man page states cc recognizes -a, -e, -r, -t, -u, and -z and passes these options and their arguments to ld. cc also passes any unrecognized options to ld with a warning. Perhaps the macro should check the value of $GCC before testing this flag? Clearly it should. I was kind of hoping that wouldn't be necessary, but compilers differ too much in how they handle unknown options. Note that we already have a workaround for clang for the same issue, but I doubt we can rely on a similar workaround for Sun CC (and all the other myriad compilers out there). Thanks for the report, I'll look into fixing this. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: How to change paths on an external file without a full update --depth infinity?
It commits a new revision of what the file external pointed to - pretty handy. If you are pegged, it will not automagically update your pegged revision (as I'd expect), so unless you are on the HEAD or update your peg to what just committed, an update will revert your WC back to the pegged version. I'd actually expect it to be pretty confusing if you had multiple people committing changes based from different back-rev pegged references anywhere near the same time frame. Does your external 'notify about new versions' tool help with that? Don't you get conflicting changes that you'd want branches to help isolate? Yes, its obvious to users when they are not on the latest revision of the file, but they c/would still go through a merge process if need be. Its actually very straight-forward as we intentionally focused on targeting non-CM-guru folks.
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 4:03 PM, dlel...@rockwellcollins.com wrote: I'd actually expect it to be pretty confusing if you had multiple people committing changes based from different back-rev pegged references anywhere near the same time frame. Does your external 'notify about new versions' tool help with that? Don't you get conflicting changes that you'd want branches to help isolate? Yes, its obvious to users when they are not on the latest revision of the file, but they c/would still go through a merge process if need be. Its actually very straight-forward as we intentionally focused on targeting non-CM-guru folks. I'm having a little trouble picturing how you would sanely maintain (say) a conflicting line of code where 2 projects need the difference across several revisions when all the commits from both go to the head of the same trunk copy. -- Les Mikesell lesmikes...@gmail.com
Re: How to change paths on an external file without a full update --depth infinity?
On 8/15/13 1:05 PM, Les Mikesell wrote: I'd actually expect it to be pretty confusing if you had multiple people committing changes based from different back-rev pegged references anywhere near the same time frame. Does your external 'notify about new versions' tool help with that? Don't you get conflicting changes that you'd want branches to help isolate? The commit won't complete you'll get an out of date error.
Re: How to change paths on an external file without a full update --depth infinity?
Ben Reser bre...@apache.org wrote on 08/15/2013 02:57:23 PM: On 8/15/13 1:05 PM, Les Mikesell wrote: I'd actually expect it to be pretty confusing if you had multiple people committing changes based from different back-rev pegged references anywhere near the same time frame. Does your external 'notify about new versions' tool help with that? Don't you get conflicting changes that you'd want branches to help isolate? The commit won't complete you'll get an out of date error. That's right, isn't it. It'd be no different than two folks trying to commit the same file around the same time, right (one would get an out of date error)? Thanks, Dan
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 5:14 PM, dlel...@rockwellcollins.com wrote: I'd actually expect it to be pretty confusing if you had multiple people committing changes based from different back-rev pegged references anywhere near the same time frame. Does your external 'notify about new versions' tool help with that? Don't you get conflicting changes that you'd want branches to help isolate? The commit won't complete you'll get an out of date error. That's right, isn't it. It'd be no different than two folks trying to commit the same file around the same time, right (one would get an out of date error)? Right, but when working on the trunk explicitly you'd expect to update to accept others' changes often, or to branch to preserve and isolate your differences. I don't see how either quite matches a model where changes might be made based on multiple differing back-rev pinned externals. What happens if two projects don't want to accept each others' changes and need to commit their own? In a more typical scenario they would be working on branch copies that could diverge, but I think you lose that by forcing a canonical path for development (as a tradeoff for knowing where the 'new' work is...). -- Les Mikesell lesmikes...@gmail.com
Re: How to change paths on an external file without a full update --depth infinity?
The commit won't complete you'll get an out of date error. That's right, isn't it. It'd be no different than two folks trying to commit the same file around the same time, right (one would get an out of date error)? Right, but when working on the trunk explicitly you'd expect to update to accept others' changes often, or to branch to preserve and isolate your differences. I don't see how either quite matches a model where changes might be made based on multiple differing back-rev pinned externals. What happens if two projects don't want to accept each others' changes and need to commit their own? In a more typical scenario they would be working on branch copies that could diverge, but I think you lose that by forcing a canonical path for development (as a tradeoff for knowing where the 'new' work is...). If a project doesn't want to accept a change, they fork to a new history. The tool does this with a svn cp old_pedigree/foo.c new_pedigree/foo.c and an update to the svn:externals property. They now lose sight of what the other project commits after that fork though. The backend of where the file is stored and how is masked by the tool. pedigree is essentially implemented as a folder. To the developer, they may know that their file is really a file external, but they don't treat it really any different from a normal file until it comes time to fork. I try to differentiate forking as a pedigree/history from branching and the like. This system is essentially an implementation of Rational's CMVC history feature.
Re: How to change paths on an external file without a full update --depth infinity?
On Thu, Aug 15, 2013 at 6:09 PM, dlel...@rockwellcollins.com wrote: If a project doesn't want to accept a change, they fork to a new history. The tool does this with a svn cp old_pedigree/foo.c new_pedigree/foo.c and an update to the svn:externals property. They now lose sight of what the other project commits after that fork though. The backend of where the file is stored and how is masked by the tool. pedigree is essentially implemented as a folder. To the developer, they may know that their file is really a file external, but they don't treat it really any different from a normal file until it comes time to fork. I try to differentiate forking as a pedigree/history from branching and the like. This system is essentially an implementation of Rational's CMVC history feature. In subversion's view a copy is a branch so any distinction is strictly your own convention. Likewise for tags, except that there is a generally accepted convention of not committing changes after a tag copy. Do you have additional conventions or tools to help users of the pre-fork version know that it has branched?I don't think there is a generic solution for that - subversion tracks copy-from history, but not copy-to. -- Les Mikesell lesmikes...@gmail.com
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Philip Martin Sent: Thursday, 15 August 2013 19:02 PM Geoff Field writes: I've just commented out the AuthzSVNAccessFile line and have done the following: This time, I changed the AuthType line to AuthType None for the Subversion location. Similar test (but with fewer typos this time). C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test7.txt ASVN_Test\test.txt Checked out revision 898. C:\cd SVN_Test C:\SVN_Testcopy test.txt test9.txt 1 file(s) copied. C:\SVN_Testsvn add test9.txt A test9.txt C:\SVN_Testsvn ci test9.txt --message test9 Adding test9.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test9.txt' is out of date svn: E175005: File 'test9.txt' already exists C:\SVN_Testsvn ci test6.txt --message test 1.8.1 checkin Adding test6.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date svn: E175005: File 'test6.txt' already exists Same error report persisting. 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1 201 439 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] HEAD /Subversion/Playground/trunk/test6.txt HTTP/1.1 401 - 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 401 580 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 204 - That still shows 401 unauthorized which is odd if you are not using Authz. Do you have some other authz beyond AuthzSVNAccessFile? It could be the SSL layer. The location section does contain the following line: SSLRequireSSL Still showing: ... 0.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:24 +1000] CHECKOUT /Subversion/Playground/!svn/ver/898/trunk HTTP/1.1 201 439 10.63.36.64 - - [16/Aug/2013:09:39:25 +1000] HEAD /Subversion/Playground/trunk/test9.txt HTTP/1.1 401 - 10.63.36.64 - - [16/Aug/2013:09:39:26 +1000] DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1 401 580 10.63.36.64 - - [16/Aug/2013:09:39:27 +1000] DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:27 +1000] DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1 204 - The 1.2.3 client simply shows that with neon we don't send HEAD. Again, the error log did not change. You may get more information if you add LogLevel debug I did that, too. I'll email the full results privately, as the 3000-odd lines resulting from this set of transactions is a bit too big for a group email. The final sections of the error log say this, though: ... [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1490): +-+ [Fri Aug 16 09:39:25 2013] [info] Subsequent (No.11) HTTPS request received for child 249 (server aapleng1.aapl.com.au:443) [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 bytes expected to read on BIO#1114588 [mem: 121bae8] [Fri Aug 16 09:39:25 2013] [info] Connection to child 248 established (server aapleng1.aapl.com.au:443, client 10.63.36.64) [Fri Aug 16 09:39:25 2013] [info] (70014)End of file found: SSL input filter read failed. [Fri Aug 16 09:39:25 2013] [info] Seeding PRNG with 136 bytes of entropy [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1794): OpenSSL: Write: SSL negotiation finished successfully [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1776): OpenSSL: Handshake: start [Fri Aug 16 09:39:25 2013] [info] Connection to child 249 closed with standard shutdown(server aapleng1.aapl.com.au:443, client 10.63.36.64) [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1784): OpenSSL: Loop: before/accept initialization [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1512): OpenSSL: read 11/11 bytes from BIO#112df18 [mem: 52345e0] (BIO dump follows) [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1459): +-+ ... [Fri Aug 16 09:39:27 2013] [info] Subsequent (No.2) HTTPS request received for child 248 (server aapleng1.aapl.com.au:443) [Fri Aug 16 09:39:27 2013] [info] [client 10.63.36.64] Access granted: 'AAPL\\gf' DELETE Playground: [Fri Aug 16 09:39:27 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 bytes expected to read on BIO#112df18 [mem: 52345e0] [Fri Aug 16 09:39:27 2013] [info] (70014)End of file found: SSL input filter read failed. [Fri Aug 16 09:39:27 2013] [debug] ssl_engine_kernel.c(1794): OpenSSL: Write: SSL
RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)
Thanks to everybody for their patience with my issue. The root cause is not really solved, but at least I (and my colleagues) can get back to normal work patterns. I've finally managed to get the upgrade to Apache 2.2 and SVN server 1.6.9 running. As it turns out, my former colleagues had deliberately configured all the ports one up from the default (thus, SSL was running on port 444 instead of the default 443). Once I'd fixed this, Apache 2.2 started serving SVN via the default interfaces. With that, I can now run everything happily. I have not deleted the Apache 2.0/SVN server 1.2.3 configuration, so I should be able to switch back to that if needed. I suppose it's possible some repositories might become inaccessible to the earlier server due to the server upgrade, but I'm not particularly fussed about that. Regards, Geoff -- Geoff Field - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
