[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Resolution of 'svn diff' change?

From: Colin Watson <cjwatson_at_flatline.org.uk>
Date: 2003-05-19 16:35:56 CEST

On Mon, May 19, 2003 at 03:55:48PM +0200, Sander Striker wrote:
> Note that the iterative functionality can be easily done using a wrapper.
> Whereas the new functionality cannot.
>
> Can someone from the pro-iterative camp speak up and tell us if a wrapper
> would be that bad?

I don't relish the thought of trying to tell ex-CVS users that they need
some external wrapper to do something which is an utterly trivial
application of 'cvs diff', to be honest ... it would be nearly as bad as
the way 'p4 submit' can only submit one file, which as was mentioned
here a little while back is only mitigated by the fact that you can edit
its list of files while composing the commit message.

Also, a wrapper will be much slower than letting 'svn diff' do all the
files at once if your connection to the server has high setup time.
Consider svn+ssh to a distant machine. I do this frequently with CVS,
and a wrapper calling 'svn diff' multiple times would be *painful*.

  $ time cvs diff lib/hashtable.c >/dev/null
  
  real 0m4.390s
  user 0m0.030s
  sys 0m0.000s
  $ time cvs diff lib/hashtable.[ch] >/dev/null
  
  real 0m4.573s
  user 0m0.030s
  sys 0m0.010s
  $ time cvs diff lib/hashtable.[ch] src/lexgrog.l src/man.c src/ult_src.c >/dev/null
  
  real 0m5.785s
  user 0m0.130s
  sys 0m0.020s

6 seconds is bearable; over 20 seconds would be pretty much unusable.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 16:36:48 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.