[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: <cmpilato_at_collab.net>
Date: 2003-05-19 15:36:44 CEST

Justin Erenkrantz <justin@erenkrantz.com> writes:

> I just realized that I really like (and rely upon):
>
> svn diff dir/x dir/y
>
> meaning dir/x and dir/y relative to the repository (as cached in the wc).
>
> AIUI, this is now going to be a fatal error. Is that correct?

No. It will mean diff dir/x against dir/y.

> I have a hunch that the 'diff' interface should be parallel to the
> 'commit' interface - that is, they should accept the same semantics.
> (View diff as a dry-run of a commit.)

The problem is that diff has soooooooo much more to do than commit
does. Commit is about sending files from the working copy to the
repository, period. You don't even get to specify where in the
repository you want to put the files.

Diff, on the other hand, is pulling files from arbitrary locations --
and revisions -- in the working copy and repository. I am confident
that without adding a clunky option or a new subcommand, 'svn diff'
canNOT be all things that folks want it to be.

As for trying to match commit's interface? Nonsense. If there are
two interfaces that need to be matched, I think they should be 'svn
diff' and 'svn merge' (where svn diff's missing third "target"
parameter is 'stdout'). I constantly use 'svn diff' to diff between
two things as a sort of trial merge.

So, to maintain the iterative diff functionality, I suggest we do one
of a few things:

  1. revert 'svn diff' back to its interative,
     base-versus-working-file state,

  2. then, either:

     a. add a new 'svn compare' subcommand to handle the 2-target
        comparitive diff case, or

     b. give 'svn merge' the extra diff responsibilities, either by:
  
        i. adding --dry-run flag, or

        ii. by making the absence of an explicity third merge argument
            mean "just gimme the diff to stdout".

where (2a) is the only truly sensible decision in my mind.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 15:42:59 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.