Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: >> Even if we assume that it's impossible to upgrade OpenSSH on a given >> platform for some weird reason, > > I appreciate your effort in this, but I strongly suggest that you > refrain from calling reasons why people can't install the latest > versions of supporting tools "weird".
Wrong choice of words, I apologize. I should have written "any given reason", or simply "any reason". >> the problem is probably going to be fixed by SVN 1.4 and >> the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live >> with a slower "svn diff -rR1 -rR2" remote operation. Sorry about that, but >> let's not remember of the other dozens which works on branches and can do >> a merge in seconds instead of literally *hours*, and so on. > > I was fearing that. I am of the opinion that we wait for a stable SVN 1.4. I would like to notice that a fair comparison should take into account the fact that a single "svn diff" shows a whole changeset of changes (accounting multiple files). With cvs, you might need to run multiple "cvs diff" (with multiple SSH handshakes), plus the time to write all those different revision numbers for each file. So, while the raw time for a single command is slower, I believe that, in the common case, the operation still ends up being faster, if expressed in "seconds to do what I want". In other words, what I see mostly in this thread is that people are worried because of what we usually call "micro-benchmarks" (e.g. "raw cvs diff time for a single time across two revisions"), which is of course important (and svn is mostly faster except a couple of corner-cases); but some seem to miss that real-world workflow benchmarks (e.g. "time to backport a patch") are several times better with svn, because of the higher-level commands and concepts it provides. I'd also remember that this issue (diff of a single file across SSH being slower) can be fixed by either an OpenSSH upgrade (which should be flawless in many cases), or a svn:// readonly access (which I still have to understand if it can be done), or the use of svk which lets you mirror part of the repository (including history) locally (e.g. everything since gcc 3.0) so that all the diff/checkout/switch/whatnot operations are blazingly fast (at the expense of some disk space). -- Giovanni Bajo
