You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu> on 2001/09/04 19:49:08 UTC
Re: [SVN-DEV] Re: [Issue 422] Changed - "svn diff" needs to be
fleshed out.
On 4 Sep 2001, Ben Collins-Sussman wrote:
> 1. svn diff foo.c
> 2. svn diff -r 5 -r 7 foo.c
> 3. svn diff -r 5 foo.c
So, are you saying that if the user has a (client-side) custom diff
program installed, that case 1 will behave (possibly radically)
differently from 2 and 3?
This seems like a misfeature. Why not check out the revisions into
temporary files and then run the client-side diff? Slightly more
inefficient, perhaps, but cooperates much better with the user's
preferences. (The 'efficient' way to do this is to generate *svn* diffs
between revisions, apply them to the working copy to create a pair of
temporary files, and *then* run the user's 'diff' program on the pair.
This way you get the efficiency of the server-side approach (since the
server "knows" the diffs) with the consistency of the client-side model.)
--s
Dictionary planning President Bejing UKUSA Cocaine Iraq nuclear chemical agent
global action network munitions anthrax biowarfare early warning Indonesia
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <si...@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] Re: [Issue 422] Changed - "svn diff" needs to be fleshed out.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Sep 04, 2001 at 02:52:33PM -0500, Ben Collins-Sussman wrote:
>...
> > (The 'efficient' way to do this is to generate *svn* diffs between
> > revisions, apply them to the working copy to create a pair of
> > temporary files, and *then* run the user's 'diff' program on the
> > pair. This way you get the efficiency of the server-side approach
> > (since the server "knows" the diffs) with the consistency of the
> > client-side model.)
>
> Yeah, that could work. I wonder how Greg/Karl feel about this.
Posted elsewhere. Personally, the whole "custom diff" thing is bogus. "Neat
feature", say the engineers. "So what?", say the users.
> Still, our RA vtable has no way (at the moment) to request either the
> plaintext (or svndiff data) for a particular file. The latter is done
> all the time during drives of "editors", but there's no way to ask for
> that info standalone. Should be easy to do.
Two or three PROPFIND requests and a GET. Piece of cake. Already have most
of the support functions for it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] Re: [Issue 422] Changed - "svn diff" needs to be fleshed out.
Posted by Ben Collins-Sussman <su...@collab.net>.
"C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu> writes:
> On 4 Sep 2001, Ben Collins-Sussman wrote:
>
> > 1. svn diff foo.c
> > 2. svn diff -r 5 -r 7 foo.c
> > 3. svn diff -r 5 foo.c
>
> So, are you saying that if the user has a (client-side) custom diff
> program installed, that case 1 will behave (possibly radically)
> differently from 2 and 3?
Yeah, possibly.
>
> This seems like a misfeature. Why not check out the revisions into
> temporary files and then run the client-side diff? Slightly more
> inefficient, perhaps, but cooperates much better with the user's
> preferences.
True. Maybe consistency is important here.
> (The 'efficient' way to do this is to generate *svn* diffs between
> revisions, apply them to the working copy to create a pair of
> temporary files, and *then* run the user's 'diff' program on the
> pair. This way you get the efficiency of the server-side approach
> (since the server "knows" the diffs) with the consistency of the
> client-side model.)
Yeah, that could work. I wonder how Greg/Karl feel about this.
Still, our RA vtable has no way (at the moment) to request either the
plaintext (or svndiff data) for a particular file. The latter is done
all the time during drives of "editors", but there's no way to ask for
that info standalone. Should be easy to do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] Re: [Issue 422] Changed - "svn diff" needs to be fleshed out.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Sep 04, 2001 at 03:49:08PM -0400, C. Scott Ananian wrote:
> On 4 Sep 2001, Ben Collins-Sussman wrote:
>
> > 1. svn diff foo.c
> > 2. svn diff -r 5 -r 7 foo.c
> > 3. svn diff -r 5 foo.c
>
> So, are you saying that if the user has a (client-side) custom diff
> program installed, that case 1 will behave (possibly radically)
> differently from 2 and 3?
Fitz needs to close his trap :-)
The whole "custom diff" thing is a lot of hand-waving and unnecessary
complication again. Just like that renamable .svn subdir "feature". For
starters, how are we supposed to deal with that custom diff's output? It
would probably need to produce the svndiff format; if it does, then it
probably means we wrote it; if so, then why is it "custom" rather than just
part of SVN?
Pluggable diffs and all the nastiness that comes with that is definitely a
post 1.0 item. IMO, just say no. :-)
> This seems like a misfeature. Why not check out the revisions into
> temporary files and then run the client-side diff? Slightly more
> inefficient, perhaps, but cooperates much better with the user's
> preferences. (The 'efficient' way to do this is to generate *svn* diffs
> between revisions, apply them to the working copy to create a pair of
> temporary files, and *then* run the user's 'diff' program on the pair.
> This way you get the efficiency of the server-side approach (since the
> server "knows" the diffs) with the consistency of the client-side model.)
For case 2: an svndiff with context from the server; no files transmitted.
For case 3: one file transmitted.
Note in all cases, we will eventually be using compression on those
transfers. Sending a file can still be expensive, but we can at least reduce
that expense :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org