Re: How to choose between svn http?
On Thu, Jul 29, 2010 at 22:40, David Weintraub qazw...@gmail.com wrote: The standard 'svn' protocol is faster, but it uses port 3690 by default. It is very likely that your VPN will block traffic to this port. Why so? You can start svnserve on another port, and you can use ssh+svn which allows for tunneling. I believe you can have a Subversion repository run using both the svn:// protocol and the http:// protocol at the same time It's nice to hear so. But since I'm using Visual SVN server, I think I have to turn to that company to see if their product supports this dual-port function. Thanks a lot and to the other users as well.
Re: How to choose between svn http?
On Fri, Jul 30, 2010 at 08:32, STF SVN lapsap7+...@gmail.com wrote: On Thu, Jul 29, 2010 at 22:40, David Weintraub qazw...@gmail.com wrote: The standard 'svn' protocol is faster, but it uses port 3690 by default. It is very likely that your VPN will block traffic to this port. Why so? Sane network security policies block everything, especially non-standard ports, by default. Since Subversion isn't a common piece of software, it shouldn't be a surprise if this port is locked down. You can start svnserve on another port, and you can use ssh+svn which allows for tunneling. I believe you can have a Subversion repository run using both the svn:// protocol and the http:// protocol at the same time It's nice to hear so. But since I'm using Visual SVN server, I think I have to turn to that company to see if their product supports this dual-port function. VisualSVN Server is just a distribution of Subversion bundled with Apache, a nice installer, and an MMC snap-in for server administration. Under the hood, it's still the same Subversion. It should support multiple access methods just fine.
Re: How to choose between svn http?
On Fri, Jul 9, 2010 at 07:16, David Weintraub qazw...@gmail.com wrote: Are you setting up a Subversion repository and don't know whether you should use HTTP or SVN, or does your repository allow you to access your Subversion repository both ways, and you want to know which to use. SVN is usually quicker than HTTP, but HTTP is more flexible to setup. For example, you can use an LDAP server for loggin on if you're using HTTP, but it's much more difficult to do with SVN. HTTP is also less likely to be blocked by routers. I already have a working SVN server using HTTP, but I'd like to see some other alternatives, especially those which could provide better performance. The problem right now is that some users are accessing the SVN within a VPN tunnel and things are slow for them. So, if it's possible to reduce data quantity, like using another protocol, I would take it.
Re: How to choose between svn http?
On Thu, Jul 29, 2010 at 4:59 AM, STF SVN lapsap7+...@gmail.com wrote: I already have a working SVN server using HTTP, but I'd like to see some other alternatives, especially those which could provide better performance. The problem right now is that some users are accessing the SVN within a VPN tunnel and things are slow for them. So, if it's possible to reduce data quantity, like using another protocol, I would take it. The standard 'svn' protocol is faster, but it uses port 3690 by default. It is very likely that your VPN will block traffic to this port. You can start svnserve on another port, and you can use ssh+svn which allows for tunneling. Subversion is known for simplicity, ease of use, but speed isn't one of them. The entire .svn directory thing slows Subversion down -- especially since the entire diff is kept in there. I believe you can have a Subversion repository run using both the svn:// protocol and the http:// protocol at the same time (Is this true? Somebody respond). If this is correct, you can try starting up the svnserve server and see if it improves the VPN times at all. -- David Weintraub qazw...@gmail.com
Re: How to choose between svn http?
On Jul 29, 2010, at 15:40, David Weintraub wrote: Subversion is known for simplicity, ease of use, but speed isn't one of them. The entire .svn directory thing slows Subversion down -- especially since the entire diff is kept in there. I wouldn't say Subversion is inherently slow at all. Yes, scanning the .svn directories takes time if you have a large number of directories in your working copy, but that's being totally reworked for version 1.7 so it shouldn't be a problem much longer. I believe you can have a Subversion repository run using both the svn:// protocol and the http:// protocol at the same time (Is this true? Somebody respond). Yes, there is a section of the book explaining how to do this. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.multimethod.html
Re: How to choose between svn http?
On Thu, Jul 29, 2010 at 16:40, David Weintraub qazw...@gmail.com wrote: On Thu, Jul 29, 2010 at 4:59 AM, STF SVN lapsap7+...@gmail.com wrote: I already have a working SVN server using HTTP, but I'd like to see some other alternatives, especially those which could provide better performance. The problem right now is that some users are accessing the SVN within a VPN tunnel and things are slow for them. So, if it's possible to reduce data quantity, like using another protocol, I would take it. The standard 'svn' protocol is faster, but it uses port 3690 by default. It is very likely that your VPN will block traffic to this port. You can start svnserve on another port, and you can use ssh+svn which allows for tunneling. Subversion is known for simplicity, ease of use, but speed isn't one of them. The entire .svn directory thing slows Subversion down -- especially since the entire diff is kept in there. I believe you can have a Subversion repository run using both the svn:// protocol and the http:// protocol at the same time (Is this true? Somebody respond). True. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.multimethod.html
Re: How to choose between svn http?
On Thu, Jul 8, 2010 at 10:31 PM, Alec Kloss alec.kl...@oracle.com wrote: On 2010-07-08 17:04, David Brodbeck wrote: On Jul 8, 2010, at 4:49 PM, Nico Kadel-Garcia wrote: A local comparison is often best, especially when operating over HTTPS or svn+ssh for security reasons: Because of the continuing storage of HTTP/HTTPS/svn/SSH passwords in clear-text by the UNIX or Linux versions of Subversion, I don't trust anything but the svn+ssh public key based access for public use. Unfortunately, this does cause a noticeable performance hit. It's worth pointing out that the private key has to have a passphrase, for this to be a security improvement. Otherwise all you've accomplished is to leave the password-equivalent in ~/.ssh instead of in ~/.svn. ;) I mention this only because a lot of the applications for SSH public keys involve passwordless login. [chop] I feel a little like a broken record, but... using GSSAPI (or Negotiate for HTTPS) substantially reduces the security issues by integrating authentication into the rest of a managed single-sign-on system. GSSAPI/Negotiate also has the feature of working in all four remote access protocols for Subversion. The downside is difficulty in configuration and poor support in some (or many or perhaps all) binary distributions of Subversion. I have to admit, I don't think very highly of ssh public-key authentication; I have a hard time believing very many users or administrators carefully protect, rotate, and revoke RSA keys in a timely manner, which seems to me to substantially reduce the security of ssh public-key infrastructure. It's a longstanding problem. Much as Subversion on UNIX and Linux, by default, allows the plaintext saving of passwords, the SSH key management tools allow the saving of passphrase free keys. GSSAPI is cool. It does take more setup work, and the default versions of OpenSSH on many industry standard releases do not support it, nor does the stable release of Putty. Various development versions do permit this, but then the setup has to play well with the ownership of the files on the server (which svn+ssh does by using a single designated user) or for shared account access, the setting of the correct username for logging (which svn+ssh key management does by setting svnserve command line options).
RE: How to choose between svn http?
-Original Message- From: laps...@gmail.com [mailto:laps...@gmail.com] On Behalf Of STF SVN Sent: Thursday, 8 July 2010 22:15 To: users@subversion.apache.org Subject: How to choose between svn http? As we have two protocoles, svn and http, available for subversion, I'd like to know if there's any performance comparison study on both of them to let us choose the most appropriate one. Anyone has any related article on that? TIA Perhaps try a google search? http://www.google.com.au/search?q=svn+vs+httpie=utf-8oe=utf-8aq=t # Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, 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 system and destroy any copies. #
Re: How to choose between svn http?
On Thu, Jul 8, 2010 at 7:11 PM, Keith Moore keith.mo...@securency.com wrote: -Original Message- From: laps...@gmail.com [mailto:laps...@gmail.com] On Behalf Of STF SVN Sent: Thursday, 8 July 2010 22:15 To: users@subversion.apache.org Subject: How to choose between svn http? As we have two protocoles, svn and http, available for subversion, I'd like to know if there's any performance comparison study on both of them to let us choose the most appropriate one. Anyone has any related article on that? TIA Perhaps try a google search? http://www.google.com.au/search?q=svn+vs+httpie=utf-8oe=utf-8aq=t Most of the links are useless, discussing other subject, addressing far too old of releases, or not doing a straight comparison. A local comparison is often best, especially when operating over HTTPS or svn+ssh for security reasons: Because of the continuing storage of HTTP/HTTPS/svn/SSH passwords in clear-text by the UNIX or Linux versions of Subversion, I don't trust anything but the svn+ssh public key based access for public use. Unfortunately, this does cause a noticeable performance hit. Performance can also be dominated by the size of the repository, and the use of chatty file storage technologies such as CIFS, which can seriously slow the checkout of bulky working copies with lots of files. (I've run into this recently: what took 2.5 minutes to NFS shares took 25 minutes to CIFS shares. It was embarassing!)
Re: How to choose between svn http?
On Jul 8, 2010, at 4:49 PM, Nico Kadel-Garcia wrote: A local comparison is often best, especially when operating over HTTPS or svn+ssh for security reasons: Because of the continuing storage of HTTP/HTTPS/svn/SSH passwords in clear-text by the UNIX or Linux versions of Subversion, I don't trust anything but the svn+ssh public key based access for public use. Unfortunately, this does cause a noticeable performance hit. It's worth pointing out that the private key has to have a passphrase, for this to be a security improvement. Otherwise all you've accomplished is to leave the password-equivalent in ~/.ssh instead of in ~/.svn. ;) I mention this only because a lot of the applications for SSH public keys involve passwordless login. Performance can also be dominated by the size of the repository, and the use of chatty file storage technologies such as CIFS, which can seriously slow the checkout of bulky working copies with lots of files. (I've run into this recently: what took 2.5 minutes to NFS shares took 25 minutes to CIFS shares. It was embarassing!) Virus scanning overhead can really bite you here, too. -- David Brodbeck System Administrator, Linguistics University of Washington
Re: How to choose between svn http?
On 2010-07-08 17:04, David Brodbeck wrote: On Jul 8, 2010, at 4:49 PM, Nico Kadel-Garcia wrote: A local comparison is often best, especially when operating over HTTPS or svn+ssh for security reasons: Because of the continuing storage of HTTP/HTTPS/svn/SSH passwords in clear-text by the UNIX or Linux versions of Subversion, I don't trust anything but the svn+ssh public key based access for public use. Unfortunately, this does cause a noticeable performance hit. It's worth pointing out that the private key has to have a passphrase, for this to be a security improvement. Otherwise all you've accomplished is to leave the password-equivalent in ~/.ssh instead of in ~/.svn. ;) I mention this only because a lot of the applications for SSH public keys involve passwordless login. [chop] I feel a little like a broken record, but... using GSSAPI (or Negotiate for HTTPS) substantially reduces the security issues by integrating authentication into the rest of a managed single-sign-on system. GSSAPI/Negotiate also has the feature of working in all four remote access protocols for Subversion. The downside is difficulty in configuration and poor support in some (or many or perhaps all) binary distributions of Subversion. I have to admit, I don't think very highly of ssh public-key authentication; I have a hard time believing very many users or administrators carefully protect, rotate, and revoke RSA keys in a timely manner, which seems to me to substantially reduce the security of ssh public-key infrastructure. -- alec.kl...@oracle.com Oracle Middleware The views expressed are my own and do not necessarily reflect the views of Oracle PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEBD1FF14 pgpNbYROMon9k.pgp Description: PGP signature
