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

Re: svn diff interface

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-05-09 21:47:41 CEST

sam th <sam@uchicago.edu> writes:

> On Thu, 2002-05-09 at 14:00, Philip Martin wrote:
>
> > Yes, but I would prefer to drop the iterative case :-) I don't use it,
> > I think it makes the interface harder to understand, it makes the code
> > harder to write and test, and it makes the interface less consistent
> > with other svn functions.
>
> <unlurk>
> The iterative case is really quite useful. For example, say I've
> changed lots of files in my WC, but I only want to get the diffs for
> foo.c and bar.h. There are lots of times I want to do this. Then, with
> cvs,
> % cvs diff foo.c bar.h > patch
> does just what I want.
> % svn diff foo.c > patch && svn diff bar.h >> patch
> is lots less user-friendly.

On the other hand I can run

     % svn merge wc_path1 wc_path2 .

to merge the differences between wc_path1 and wc_path2 into the
current directory. But I can't simply look at the differences first,
because

    % svn diff wc_path1 wc_path2

doesn't work. I might be able to use

    % diff -r -x .svn wc_path1 wc_path2

but that doesn't limit itself to just versioned items, it will try to
compare everything, object files, lex/yacc output etc. This might
be better

    % diff -r -x .svn -x '*.o' wc_path1 wc_path2

but I have got to hope I can construct -x rules that are appropriate
for the entire hierarchy. This still doesn't have ancestor information
so there are corner cases where it won't do the right thing.

Maybe it's because I am not a big CVS user (although I have used it)
but I never run the iterative case.

-- 
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 9 21:48:49 2002

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