should be neccessary to call svn cleanup only in case a command got killed, not in case of an error
Hey guys! My new issue 3739 is about fixing svn cleanup. Thats good. But should not ADDITIONALLY also svn ci being fixed, in a way that svn ci doesn't corrupt the WC? In my reproduction script the svn ci is not being killed by the user or the operating system. svn ci can take all action that it wants to do and can exit when it decides to. The mv (with missing svn before the mv) does *not* corrupt the WC. (See http://subversion.tigris.org/issues/show_bug.cgi?id=3739.) You can read this from the fact, that a svn st -u command will terminate normally (will just report report file a as being missing and file 1/a as being unknown). It's the svn ci, that corrupts the WC. This also can be seen by submitting a svn st -u command. Obviously currently svn ci already notices that something goes wrong (because it is able to print out error messages). What about the idea of adding something to that error handler to save the WC? If calling the svn cleanup code is to fuzzy, what about trying to restore the WC in the version before the svn ci call? In the end, svn ci is something like a transaction. In case the transaction fails, should not the WC be rolled back to the state before the call? Or (other solution), svn ci could notice *before* starting to change the WC, that the call will fail (by noticing that file a is missing), and then exit, before the WC is changed. This would save the rollback work. What do you think? Greetings Paul.
Re: Subversion 1.6.13 Released
On Sun, Oct 24, 2010 at 6:50 AM, Andrey Repin anrdae...@freemail.ru wrote: Greetings, All! Sorry... Did I miss something? I see, CollabNet only providing bare client and big pack. If I need Subversion without Apache, should I look elsewhere? I already have Apache installation, which isn't easy to maintain. And I don't want to screw it any further installing yet another all-in-one monstrocity. (Been there, done that mistake in the past) Erm... actually, forget that. I don't have account and don't see the need for registration just to be able to download one file. It's not for you: it's for them. I don't work for them, but I've certainly seen software projects where the investors, or business partners, or middle management types in sales, wanted metrics on downloads to point to and say this many people grabbed the download, and they followed up with this many actual sales. I'll hardly begrudge them that, since they do seem to be contributing heavily to the open source version's features and design. It's also so common, I find it worthwhile to maintain a throwaway email account for just such uses, and there are even some *fascinating* anti-spam tools that generate and expire one-use email accounts you can consider using if it's irksome enough in the long run.
Re: Subversion 1.6.13 Released
Greetings, Nico Kadel-Garcia! the open source version's features and design. It's also so common, I find it worthwhile to maintain a throwaway email account for just such Which often banned on the holder's mail server... Been there, too. But as I said, if there's no required download at all, I'm not interested in registration either way. My only concern for now is strange interaction of subversion client compiled by David Darj with server using NTLM authentication. It listing and retrieving files without a problem, but failing at commit. Both read and write access require proper authentication. Just want to confirm if it is compilation, configuration or something else. -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.10.2010, 21:32 Sorry for my terrible english...
Re: Subversion 1.6.13 Released
Greetings, David Darj! David, I have a strange issue with binaries you provided. I'm using SVN repository served by Apache under Win32. In attachment is a httpd-modules-svn.conf - module loading. Enabling it... here: VirtualHost * ServerName svn.darkdragon ServerAlias svn.rootdir.org DocumentRoot C:/home/svn AddDefaultCharset utf-8 ErrorLog C:/home/svn/.log/error_log CustomLog C:/home/svn/.log/access_log common env=!SVN-ACTION CustomLog C:/home/svn/.log/svn_access_log svn env=SVN-ACTION IfModule rewrite_module some rewrite rules, they are convoluted and pretty much meaningless /IfModule Location / #AllowOverride Limit AuthConfig #Options None Order allow,deny Allow from 192.168.1.10 IfModule dav_svn_module DAV svn SVNParentPath C:/home/svn /IfModule IfModule sspi_auth_module Allow from all AuthName Subversion repository AuthType SSPI SSPIAuth On SSPIAuthoritative On SSPIOfferBasic On SSPIOmitDomain On SSPIUsernameCase lower SSPIBasicPreferred Off # only developers may access the repository Require group DAEMON1\CVS # And they should obey to SVN user permissions file IfModule authz_svn_module AuthzSVNAccessFile C:/home/svn/.registry /IfModule /IfModule /Location /VirtualHost Everything works fine, when I operate with small files. But once I start submittings megabytes of data (~500 files, ~10Mb size total), Subversion start to break on authorization, randomly asking for password or username, again and again. I don't quite know, if it is specific to your builds, or is a bug in Subversion. I'll be glad to present any additional info. -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.10.2010, 21:54 Sorry for my terrible english... httpd-modules-svn.conf Description: Binary data
Re: Subversion 1.6.13 Released
Greetings, All! Quick add: Transmitting file data .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** Authentication realm: http://svn.darkdragon:80 Subversion repository Username: anrdaemon Password for 'anrdaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** Authentication realm: http://svn.darkdragon:80 Subversion repository Username: anrdaemon Password for 'anrdaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** Authentication realm: http://svn.darkdragon:80 Subversion repository Username: anrdaemon Password for 'anrdaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Authentication realm: http://svn.darkdragon:80 Subversion repository Password for 'AnrDaemon': ** .. Committed revision 49. ls -kgoA of committed directory in attachment... -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.10.2010, 22:18 Sorry for my terrible english... files.list Description: Binary data
Re: Compiling mod_dav_svn against an installed Apache2 instance ?
Finally I followed the Synology wiki, which made me install a parallel version of Apache with all working dependencies. It should keep me safe of any update of Synology's Apache. Thank you very much for your time, guys. 2010/10/18 Loritsch, Berin blorit...@dtri.net: From: Nelson Cabral [mailto:nelson.cab...@gmail.com] Not installed (find which don't return anything). I guess I have to install apache-devel, haven't I? Are there instructions somewhere? 'apache-devel' on google returns nothing :-/ Most linux distribution packages separate the compiled binary and the develepment package (include headers and link libraries). If you built the tool from scratch you would have everything at your disposal, although the process is a little more difficult. There's a couple reasons for this practice: 1) A significant number of linux boxes are still servers at heart. That means you are deploying to them, not compiling on them. 2) In internet DMZs, boxes need to be hardened. That means no compilers, no compiler artifacts, as well as a number of other security features. By separating the packages folks who need to do compilation can, and folks who need to harden their servers can. Confidentiality Note: The information contained in this message, and any attachments, may contain proprietary and/or privileged material. It is intended solely for the person or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Re: Subversion 1.6.13 Released
On 2010-10-24 20:12, Andrey Repin wrote: Greetings, David Darj! David, I have a strange issue with binaries you provided. I'm using SVN repository served by Apache under Win32. In attachment is a httpd-modules-svn.conf - module loading. Enabling it... here: VirtualHost * ServerName svn.darkdragon ServerAlias svn.rootdir.org DocumentRoot C:/home/svn AddDefaultCharset utf-8 ErrorLog C:/home/svn/.log/error_log CustomLog C:/home/svn/.log/access_log common env=!SVN-ACTION CustomLog C:/home/svn/.log/svn_access_log svn env=SVN-ACTION IfModule rewrite_module some rewrite rules, they are convoluted and pretty much meaningless /IfModule Location / #AllowOverride Limit AuthConfig #Options None Order allow,deny Allow from 192.168.1.10 IfModule dav_svn_module DAV svn SVNParentPath C:/home/svn /IfModule IfModule sspi_auth_module Allow from all AuthName Subversion repository AuthType SSPI SSPIAuth On SSPIAuthoritative On SSPIOfferBasic On SSPIOmitDomain On SSPIUsernameCase lower SSPIBasicPreferred Off # only developers may access the repository Require group DAEMON1\CVS # And they should obey to SVN user permissions file IfModule authz_svn_module AuthzSVNAccessFile C:/home/svn/.registry /IfModule /IfModule /Location /VirtualHost Everything works fine, when I operate with small files. But once I start submittings megabytes of data (~500 files, ~10Mb size total), Subversion start to break on authorization, randomly asking for password or username, again and again. I don't quite know, if it is specific to your builds, or is a bug in Subversion. I'll be glad to present any additional info. -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.10.2010,21:54 Sorry for my terrible english... Hi Andrey I have no problem committing several hundreds om MB. I got no possibility to test with SSPI authentication though. Can you test without it and see if it works? /David
configure svn to use a SOCKS proxy for specific hosts.
I would like interact with a http subversion repository which is not directly available offsite. There is a SOCKS proxy and a VPN available, either of which would allow access to the repo. I do not want to install a solution as heavy-weight as VPN, so I was hoping that there was a clean way to use the SOCKS proxy. I did find that .subversion/servers file supports various http-proxy-* properties, but as far as I know this is not sufficient for a SOCKS proxy. Any help would be appreciated, I am on Mac 10.6 with svn 1.6.5. --Jeff
