You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2003/05/19 07:42:08 UTC
Resolution of 'svn diff' change?
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? I'm not really
clear what the resolution was with that thread as it went off in a million
tangents. So, pardon my request for clarification.
IMHO, this is *very* useful when you have local changes that you haven't
committed and only want a partial 'diff' subset of a directory. I use it as:
svn diff dir/x dir/y | less
to review my local changes where dir/z is also modified and I don't want to
see its diff output (and ignoring it if it is present in the diff makes it too
hard to review). Am I now going to have to do:
svn diff dir/x >1
svn diff dir/y >>1
less 1
or
for i in dir/x dir/y; do svn diff $i | less; done
whereas
svn ci dir/x dir/y
would still work as expected? (Or, will commit reject the iterative case too?)
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.)
If the iterative case is indeed removed as I describe above, then I'm going to
seriously contemplate vetoing any change to the 'svn diff' interface that
removes the iterative case. It's going to be extremely annoying working
around this when I have lots of local mods in my working copy (which is gonna
happen more than I'd like to admit - it's a frequent occurrence in
httpd-land). Not to mention that this would be a significant regression from
CVS with no clean alternative proposed by SVN.
Sorry for the late entry into this thread, but I'm slowly trying to catch up
on this list after being away. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Stein <gs...@lyra.org>.
> On Mon, May 19, 2003 at 09:38:26AM -0500, cmpilato@collab.net wrote:
> > Colin Watson <cj...@flatline.org.uk> writes:
> > > 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*.
> >
> > Actually, it sucks with CVS because CVS's diffs require network
> > access. Subversion's don't. So your net connection won't play into
> > the cost of this change at all.
As soon as you say "diff these files against rev 5" then we also must hit
the network.
For example, let's say you want to find all API changes:
$ svn diff -r SOMEREV subversion/include/*.h
Doing that one at a time would be much more painful on the network.
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: Resolution of 'svn diff' change?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, May 19, 2003 3:56 PM +0100 Colin Watson
<cj...@flatline.org.uk> wrote:
> wrapper for what they consider a trivial use case, though. I'd
> definitely "vote" for your subcommand option (2a), since that keeps
> ordinary 'svn diff' use consistent whether you're comparing one, two,
> three, or more files between the working copy and the repository. 'svn
> compare' would have no such consistency constraints: it can only compare
> two items.
If another subcommand can keep everyone happy, that's fine with me. But,
asking *everyone* to roll their own wrapper just to match the standard
functionality of CVS seems ludicrous (and not a bikeshed, IMHO). -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Colin Watson <cj...@flatline.org.uk>.
On Mon, May 19, 2003 at 09:38:26AM -0500, cmpilato@collab.net wrote:
> Colin Watson <cj...@flatline.org.uk> writes:
> > 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*.
>
> Actually, it sucks with CVS because CVS's diffs require network
> access. Subversion's don't. So your net connection won't play into
> the cost of this change at all.
Hm, good point.
I stand by my claim that it's going to be hard to tell at least certain
classes of CVS users (e.g. me a year ago) that they have to write a
wrapper for what they consider a trivial use case, though. I'd
definitely "vote" for your subcommand option (2a), since that keeps
ordinary 'svn diff' use consistent whether you're comparing one, two,
three, or more files between the working copy and the repository. 'svn
compare' would have no such consistency constraints: it can only compare
two items.
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
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Colin Watson <cj...@flatline.org.uk> writes:
> 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*.
Actually, it sucks with CVS because CVS's diffs require network
access. Subversion's don't. So your net connection won't play into
the cost of this change at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Colin Watson <cj...@flatline.org.uk>.
On Mon, May 19, 2003 at 10:56:19AM -0400, Sergey A. Lipnevich wrote:
> Colin Watson wrote:
> >the way 'p4 submit' can only submit one file, which as was mentioned
>
> For the record, this is wrong.
I should have said "one argument", including '...' or whatever. You
can't for example say 'p4 submit foo.c bar.c'.
> Moreover, I use commands like "p4 submit subv*/..." all the time for
> cases where I want to commit changes in both "subversion" and
> "subversion-client" directories where I maintain respective packages.
Interesting. I don't think that ever worked for me when I used Perforce
(I can't check now because I've left the company in question), but the
version we were using was a few years old.
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
Re: Resolution of 'svn diff' change?
Posted by "Sergey A. Lipnevich" <se...@pisem.net>.
Just a note:
Colin Watson wrote:
> the way 'p4 submit' can only submit one file, which as was mentioned
For the record, this is wrong. It is true though that new semantics of diff is farther from that of Perforce AFAICT. I've just
checked (and the same pattern applies to "p4 submit"), and "p4 diff" will give all differences in entire WC, "p4 diff ..." will
give differences in current WC directory and subdirs, and "p4 diff FILE1 FILE2" will give changes in those files compared to how
they were before "p4 edit" was called on them. Moreover, I use commands like "p4 submit subv*/..." all the time for cases where
I want to commit changes in both "subversion" and "subversion-client" directories where I maintain respective packages.
Thanks!
Sergey,
SourceMage GNU/Linux.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Colin Watson <cj...@flatline.org.uk>.
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
Re: Resolution of 'svn diff' change?
Posted by David Mankin <ma...@ants.com>.
On Monday, May 19, 2003, at 08:58 AM, Ben Collins-Sussman wrote:
>
> Wow, that was a very long, eloquent email from Justin. Maybe
> preserving the iterative 'svn diff' case really *is* important.
I agree 100% with Justin -- what he described matches my day-to-day use
of version control to a T.
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Ben Collins-Sussman <su...@collab.net>.
Wow, that was a very long, eloquent email from Justin. Maybe
preserving the iterative 'svn diff' case really *is* important.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, May 19, 2003 at 05:06:44PM +0100, Colin Watson wrote:
> On Mon, May 19, 2003 at 08:53:04AM -0700, Justin Erenkrantz wrote:
> > The list of files that I pass to 'svn diff' may be the same as 'svn ci'
> > (which I why I said the interface is parallel - cmpilato doesn't agree with
> > that though).
>
> If it's any guide, virtually every time I commit a set of files that
> aren't the entire working copy, I do:
>
> svn di file1 file2 file3 | view -
> :q
> Up C-w C-w C-w C-a M-f M-f C-w ci Enter
Just to put myself squarely in one camp: I do the exact same thing as Colin
describes above. I'll have a bunch of different changes in my WC (for many
various reasons). When it comes time to commit, I use 'svn status' to see
what I've got. Then I sort them out into logical chunks. Then I do something
like:
$ svn diff dir1 dir2 > /tmp/d
(review /tmp/d in my xemacs window as I write the commit msg )
(recall and edit the above line to: )
$ svn commit dir1 dir2
The fact that diff and commit take the same arguments is key to the workflow
here. I group up logical chunks by specifying the narrowest parent(s) of
each chunk. When reviewing /tmp/d, I can determine whether I got the "right"
chunk. I may need to refine the subdirs or specify individual files.
Assuming it's right, then I just recall the line and edit it to commit. Then
I review /tmp/d again to determine what I need to put into the commit
message.
Rinse and repeat.
I'm of a mind to keep them all as 'svn diff' since all five options *are*
computing differences. It is simply a question of "what are the inputs?" One
thing that may help to solve the problem is to look at one case:
$ svn diff file1 file2
How does SVN know whether that is to be iterative or comparative? The rest
of the specification stuff (revs and whatnot) is relatively "easy". But what
about this one case?
I'm kind of -0 on the new 'svn compare' command since it will definitely
cause people to say "huh? how is that different?" [no pun intended :-)] But
without a new subcommand, that would imply switches of some form.
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: Resolution of 'svn diff' change?
Posted by Colin Watson <cj...@flatline.org.uk>.
On Mon, May 19, 2003 at 08:53:04AM -0700, Justin Erenkrantz wrote:
> The list of files that I pass to 'svn diff' may be the same as 'svn ci'
> (which I why I said the interface is parallel - cmpilato doesn't agree with
> that though).
If it's any guide, virtually every time I commit a set of files that
aren't the entire working copy, I do:
svn di file1 file2 file3 | view -
:q
Up C-w C-w C-w C-a M-f M-f C-w ci Enter
--
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
Re: Resolution of 'svn diff' change?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, May 19, 2003 10:29 AM -0500 Ben Collins-Sussman
<su...@collab.net> wrote:
> This is not a dig against anybody's work habits... but do you really
> maintain mulitple changesets in a working-copy? How do you deal with
> that? I've been there, and it's always such a mess. When I encounter
> a bug, I never know if it's because of one changeset or another --
> there are too many changed variables to isolate the problem.
Yes, I do. This can be a problem in projects where prior review is needed
before a commit can occur (such as httpd). Or, you may have sent off a patch
for review by the rest of the developers (even if it is mandatory). You want
to keep the change applied in your tree while the review is pending so that
you can ensure that the change keeps building if other people change the API
or a conflict occurs.
Or, you are currently working on task1, urgent task2 comes in (and is
orthogonal), you can accomplish task2, diff/commit it, then go back to task1.
And, task2 may touch files in the same directory as task1, but not the same
files.
> So when I need to switch tasks mid-stream, I'll run
>
> $ svn diff > task1.patch
> $ svn revert . -R
> $ patch -p0 < task2.patch
>
> And as a result, I almost never run 'svn diff' on a list of
> targets... I either want to look at changes to a single file, or look
> at the whole set of changes within '.'
The problem with this scenario is that if something happens to task1.patch
where a conflict occurs, you will not detect it until it is too late. (This
is besides assuming you have a pristine WC - see below.) Or, as you change
something else (while waiting for review), you find that task1 broke something
else. By keeping it applied while the patch is outstanding, you know when
something has gone wrong. For example, I could have a patch to fix a problem
and asked for review. Unknowingly, another developer could apply another fix
to the same problem. Without it in my tree, it's hard to know that a conflict
occurred. (Yes, I do read the diff logs for my projects, but I'm not
perfect...)
Furthermore, when I run 'svn diff', I know that there are certain files in a
directory that aren't significant to the current task. I also know what files
I've modified for this task - therefore, I want explicit arguments to 'svn
diff' that can be performed cleanly.
The list of files that I pass to 'svn diff' may be the same as 'svn ci' (which
I why I said the interface is parallel - cmpilato doesn't agree with that
though). For example, in httpd, we've had a number of people run 'cvs commit'
that inadvertently commit other changes that they are working on and didn't
intend to commit. This is why 'svn/cvs commit' should always have explicit
paths sent to it rather than relying upon recursive by default. But, if you
can't pass that same list of arguments to 'svn diff', then I think something
is inherently broken.
The other reason I have multiple changesets in my tree is that I have local
modifications that are not intended to be committed. For example, I have a
number of local changes to Subversion (such as APR libtool support, a number
of autoconf workarounds, svn:permissions, svn switch --rewrite, mod_dav
changes, etc.). I can't run 'svn diff .' in my Subversion working copy and
get a clean output. And, I want all of them applied because I rely upon
having them in my own builds. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Stefan Monnier <mo...@rum.cs.yale.edu>.
> Yeah, I'm failing to understand why people need 'svn diff' to default
> to the iterative case. Justin and Colin have said that the iterative
> use-case is a part of their "basic svn work-cycle", and Justin said he
> "often has multiple changesets" in his working copy.
For what it's worth, here is my experience regarding this issue,
as the maintainer of a CVS front-end:
PCL-CVS offers a display of all the modified files and ways to mark them
and operate on them (in Emacs). Some operations operate on the marked
files by default while others default to the current file only.
`diff' is one of the few operations that default "the current file only",
meaning that `cvs diff' will only be called with a single argument.
But note that this is only the "default" behavior. This default can be
changed (because people asked for it) and it can also be overridden
on a case by case basis (because I've needed it and other people have
also asked for it).
So, there is clearly a need for CVS users to call `cvs diff' on more than
a single file (or dir). But admittedly, it's not the most common use.
I don't see any particular reason for this situation to be substantially
different in Subversion, although cheap/lightweight/quick branches might
reduce the need for "iterated" diffs.
> This is not a dig against anybody's work habits... but do you really
> maintain mulitple changesets in a working-copy? How do you deal with
> that? I've been there, and it's always such a mess. When I encounter
> a bug, I never know if it's because of one changeset or another --
> there are too many changed variables to isolate the problem.
I have probably a couple hundred changesets in my working workarea for
the Emacs project. Yes, it's a mess, although a good part of those
changes a limited to a single file.
But how do you suggest I do it knowing that the time between "coding"
and "installing" can sometimes be counted in years ?
And having a hundred different workareas would not only kill
the 300MB left on my 4GB drive but it would also be a major maintenance
nightmare and wouldn't solve the problem of "testing" all those
changesets ?
Maybe my work habits aren't the best, but given the fact that it takes
a lot of work and time (additionally to coding) to get some changes
accepted into the repository, I think that any work habit will be messy,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Colin Watson <cj...@flatline.org.uk>.
On Mon, May 19, 2003 at 10:29:49AM -0500, Ben Collins-Sussman wrote:
> cmpilato@collab.net writes:
> > Yeah. "Only truly sensible" given the base assumption that the
> > iterative case is truly necessary. I've not fallen to that assumption
> > yet. :-)
>
> Yeah, I'm failing to understand why people need 'svn diff' to default
> to the iterative case. Justin and Colin have said that the iterative
> use-case is a part of their "basic svn work-cycle", and Justin said he
> "often has multiple changesets" in his working copy.
>
> (Yikes, this mail is staring to read like a Zagat Restaurant review!)
>
> This is not a dig against anybody's work habits... but do you really
> maintain mulitple changesets in a working-copy?
I do, because I often flit from task to task as ideas come to me. They
rarely overlap much in terms of code (so I make sure I don't get into a
situation where I can't track problems), but I commonly have code files,
documentation, and packaging files all open simultaneously. It's quite
easy to keep those separate, and frequently I only worry about it when
I'm preparing to commit (so at that point I'd separate the changed files
into distinct changesets). If anything goes wrong, I can always save the
patch off somewhere and revert, but I *do* use the iterative case to
verify which bit is which. One of the major reasons I use revision
control in the first place for even single-person projects is that it
stops me losing track of where I am due to my often undisciplined and
hummingbird-like working habits.
(Certainly, if two changesets start overlapping in terms of either files
or code flow, I save and revert one of them. I'm not quite that manic.
But it's entirely possible and frequent for me to have two changesets in
the same directory which don't overlap significantly, particularly in a
codebase I know well so that I know what will and won't affect something
else.)
Also, my home directory is a Subversion working copy, running at several
hundred commits at the moment. As above, having my home directory in
revision control stops me losing track of what's going on over multiple
systems and as I switch from task to task before disciplinedly finishing
and synchronizing everything. The rationale for revision control in each
case is very similar for me. So, at the moment, I have (cut-down
sample):
M .
M .bash_profile
M .bashrc
M .environment
M .gqview/accels
M .gqview/gqviewrc
A .offlineimaprc
? .putty
M .reportbugrc
M .sawfish/menus.jl
M .spamassassin/user_prefs
M .vimrc
There's absolutely no problem keeping all of this open at once;
.bash_profile and .vimrc can hardly ever interact with each other at
all. I definitely want to test configuration changes before I commit
them to use on other systems, but it would take weeks to do anything if
I insisted on doing this separately for every change; and I've got very
used indeed to the iterative case because I often want to see the
changes to e.g. just all the shell configuration files at once. For
example, testing .spamassassin/user_prefs takes some time because I have
to wait for mail to come in, so it tends to stay open a lot. I'd wager
that anyone who keeps a home directory in CVS does the same kind of
thing.
I guess that, while I do often have a number of concurrent changesets
going at once in development projects, my home directory is the
iterative case's killer app for me.
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
Re: Resolution of 'svn diff' change?
Posted by Philip Martin <ph...@codematters.co.uk>.
cmpilato@collab.net writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> I'm all for providing all the functionality we can, as long as we
> don't make the UI so cloudy as to be worthless. I really think that
> we can please everyone with 'svn diff' iteratively doing BASE:WORK,
> and 'svn compare (cmp)' doing the more complex work. And I can have
> it all coded up in a couple of hours -- the "new diff syntax" is done,
> sitting as local mods in my working copy ... changeset #1 :-)
So what interface are you proposing? I think we can cover all
possible use cases with
svn diff [-rN[:M]] [target ...]
which iterates over the targets and compares the two versions of each
target, and
svn cmp [-rN[:M]] targetA targetB
which compares the two targets against each other. The diff command
would do BASE:WORK by default, the cmp command would by default
operate on WORK for wc_path targets and HEAD for URLs.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-05-19 at 17:04, Brian Denny wrote:
> But really, *all* diff operations are comparative in nature
I agree, and I'd like to take this a little further:
We are always comparing two things. Sometimes we are narrowing the
scope of the comparison to particular files or directories within those
two things.
With the current syntax, when we "svn diff foo bar baz", we are
comparing the wc base with the wc, narrowed to foo, bar, and baz. When
we "svn diff -r 2:3 foo bar baz", we are comparing wc-url@2 with
wc-url@3, narrowed to foo, bar, and baz. When we "svn diff url@R1
url@R2", we are comparing url@R1 with url@R2, with no narrowing.
It's this observation which led me to propose "svn diff [-r M[:N]]
[--old=oldtarget] [--new=newtarget] [path ...]", and the more I think
about it, the more I think we'll be able to explain that command more
easily than we could explain anything else.
But if we do go with separate commands, I note that Perforce calls them
"diff" for the iterative case and "diff2" for the comparative case.
It's ugly, but it's relatively intuitive and we wouldn't be being
gratuitously different.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Brian Denny <br...@briandenny.net>.
>
> Well, once again, we have two camps.
>
> A bunch of people claim that examining local diffs iteratively is
> their primary use-case of 'svn diff', and a different bunch of people
> say the primary use-case is for comparing two named objects. I'm not
> sure how to resolve this.
I don't even know which camp i'm in, as far as what my 'primary use
case' is.
> Either way, I can't *possibly* imagine adding a 5th use case to 'svn
> diff'. It's already ridiculously confusing. All you people
> advocating that we add more switches -- you don't think this is true?
As far as I'm concerned, "svn diff --iterative" would work exactly the
same way as the proposed "svn zort" (assuming 'svn zort' was to cover
the iterative, not comparative case).
So either proposal has exactly the same complexity, except that you have
longer help for 'svn diff' instead of two different helps (which, I
admit, is a disadvantage of using the option, though IMO a minor one).
The only other difference is whether the user types "svn zort ..." or types
"svn diff --iterative ...".
> This is why I was supporting cmpilato's proposal to create a new
> subcommand. Brian Denny objected to naming it 'compare'... but forget
> about the name for moment. Suppose we call the new subcommand
> 'zort'. What I'm pushing for is the KISS principle. Suppose you need
> to explain differencing to a complete svn newbie. I like this
> explanation:
>
> "If you want to see your local changes, run 'svn diff'. If you
> want to compare any two things, run 'svn zort'."
My main beef is with the name, but if we have trouble with the names, it
often indicates an underlying conceptual flaw. The above explanation
suffers from the same flaw as the names: how is "seeing my local changes"
not just a special case of "comparing any two things"? The answer, IMO,
is that it *is* just a special case. Whenever you want to "see your local
changes", even in the iterative case, you're saying "here's a *set* of
files in my WC which I want to compare to the corresponding *set* in the
repository."
So, if you ignore syntactic issues, the functionality of the proposed
iterative subcommand is a subset of that of the proposed comparative
subcommand. The ONLY reason for separating them is that we can't figure
out a clean command-line syntax for specifying an arbitrary *set* of
files.
I have a semantic bias. To me it is unclean and confusing to have
one subcommand be semantically a special case of another; I object to
letting syntactic issues override that concern.
I'll still "+0" the proposal if we can come up with clearer names.
But so far, I can't think of good ones.
> At the moment, there *is* no reasonable way to explain 'svn diff':
>
How about:
Use "svn diff" to compare any two things. The various options may be
used to specify what files/revisions you want to compare. The rest is
just details.
?-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Ben Collins-Sussman <su...@collab.net>.
Robert Pluim <rp...@bigfoot.com> writes:
> > I have a hunch, though, that that's going to be difficult -- which,
> > to me, is evidence that an option is better than a new subcommand.
> > Furthermore, i'd make the comparative case the default, and use
> > '--iterative' for the iterative case, since "svn diff --comparative"
> > is IMO redundant.
> >
>
> +1 on that. The comparative option should be the default (and I'm
> tempted to say it should be the only option, but I'm anal enough to
> have one working copy per change, so I don't have the need that other
> people have expressed for the iterative version).
Well, once again, we have two camps.
A bunch of people claim that examining local diffs iteratively is
their primary use-case of 'svn diff', and a different bunch of people
say the primary use-case is for comparing two named objects. I'm not
sure how to resolve this.
Ghudson did make a good point about 'svn diff' not necessarily losing
the -r flag.
Either way, I can't *possibly* imagine adding a 5th use case to 'svn
diff'. It's already ridiculously confusing. All you people
advocating that we add more switches -- you don't think this is true?
This is why I was supporting cmpilato's proposal to create a new
subcommand. Brian Denny objected to naming it 'compare'... but forget
about the name for moment. Suppose we call the new subcommand
'zort'. What I'm pushing for is the KISS principle. Suppose you need
to explain differencing to a complete svn newbie. I like this
explanation:
"If you want to see your local changes, run 'svn diff'. If you
want to compare any two things, run 'svn zort'."
At the moment, there *is* no reasonable way to explain 'svn diff':
"If you want to see your local changes, run 'svn diff' with no
arguments. If you want to compare any two things, then start
adding -r switches (with either one or two revisions), or @
switches attached to urls, [or possibly an --incremental option.]"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Robert Pluim <rp...@bigfoot.com>.
> I have a hunch, though, that that's going to be difficult -- which,
> to me, is evidence that an option is better than a new subcommand.
> Furthermore, i'd make the comparative case the default, and use
> '--iterative' for the iterative case, since "svn diff --comparative"
> is IMO redundant.
>
+1 on that. The comparative option should be the default (and I'm
tempted to say it should be the only option, but I'm anal enough to
have one working copy per change, so I don't have the need that other
people have expressed for the iterative version).
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Brian Denny <br...@briandenny.net>.
On Mon, May 19, 2003 at 11:37:09AM -0500, cmpilato@collab.net wrote:
>
> $ svn help compare
> compare (cmp): display the differences between two paths.
[snip]
>
> $ svn help diff
> diff (di): display local working copy modifications
We've been using the word "comparative" in this thread to mean "not
iterative", and so it sort of makes sense to us, in context, to call the
iterative operation "svn diff" and the non-iterative one "svn compare".
But really, *all* diff operations are comparative in nature, and anyone
who hasn't witnessed the evolution of these commands is going to look at
them and say, "what the heck is the difference between 'diff' and
'compare'?!?".
So i'm -0 on this as it stands, and +0 if we can come up with a
name(s) for the subcommand(s) which do a better job of making clear what
the difference is between them.
I have a hunch, though, that that's going to be difficult -- which,
to me, is evidence that an option is better than a new subcommand.
Furthermore, i'd make the comparative case the default, and use
'--iterative' for the iterative case, since "svn diff --comparative"
is IMO redundant.
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
cmpilato@collab.net writes:
> Ben seemed convinced, but asked for those two usage messages. Here
> they are:
>
> $ svn help compare
> compare (cmp): display the differences between two paths.
> usage: 1. compare [-r N[:M]] [TARGET]
> 2. compare TARGET1[@N] TARGET2[@M]
>
> Display the differences between two targets (one of which may be implied)
> in a format suitable for use with most 'patch' programs.
>
> 1. In the first syntax, TARGET is either a working copy path
> or URL. If no TARGET is specified, a value of '.' is assumed.
> Use the -r option to specify revision ranges -- if TARGET is a
> URL, this defaults to HEAD:PREV; if TARGET is a working copy
> path, the default is to display local modifications.
>
> 2. If the alternate syntax is used, TARGET1 and TARGET2
> (perhaps at specified revisions N and M, respectively) will
> be compared against each other.
I should also note that we could lose the '@'-syntax stuff and use
-rN:M in the second form, though I think this is less intuitive than
using the @'s.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> I'm willing to accede to a new subcommand, but as Phillip notes:
>
> * svn diff should take -r options.
> * svn compare should demand two arguments.
>
> I'll note that there is still a piece of functionality from CVS which
> these two commands don't encompass, specifically "compare foo and bar
> and baz from my working directory against the vendor branch". In CVS,
> that's "cvs diff -r vendor foo bar baz"; in svn, we would need a way to
> say "svn compare vendor-url . foo bar baz" or something like that. In
> one of the long-ago debates, I proposed a unified syntax which would
> handle it.
Well, I toyed with proposing something as nasty as a single command:
1. svn diff --compare [-rN:M] PATH1-LFT PATH1-RGT [PATH2-LFT PATH2-RGT ...]
2. svn diff [-rN:M] [PATH [...]]
In other words, --compare requires an even number of targets, each
pair compared to each other, possibly using the -r modifiers (or gosh,
we could use '@'-syntax here for *real* precision.
But this is just getting sick, folks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> 1. show local mods in a working copy
> svn diff
> (or: svn diff file1 file2 ..., if only for some files/dirs)
>
> 2. compare a wc path with a different version of itself
> svn diff -r M path
> (or: svn diff --old=url[@REV] path, to compare against a branch)
>
> 3. compare two specific versions of a wc path
> svn diff -r M:N path
> (or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
> path in two different branches)
I'd like to be able to do
svn diff -r N:M URL
as well, I use that quite a lot.
> 4. compare any two arbitrary repos paths/revs
> svn diff --old=url1[@REV] --new=url2[@REV]
>
> 5. compare a wc path to an arbitrary repos path
> svn diff --old=url1[@REV] --new=path
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> Greg Hudson <gh...@MIT.EDU> writes:
>
> > > Ghudson, I think your proposal has some promise. But for those of us
> > > who are a bit slow-witted, can you demonstrate how your --old/--new
> > > diff syntax would be used to cover all five use-cases I outlined in
> > > the earlier mail? Humour me... :-)
> >
> > 1. show local mods in a working copy
> > svn diff
> > (or: svn diff file1 file2 ..., if only for some files/dirs)
> >
> > 2. compare a wc path with a different version of itself
> > svn diff -r M path
> > (or: svn diff --old=url[@REV] path, to compare against a branch)
> >
> > 3. compare two specific versions of a wc path
> > svn diff -r M:N path
> > (or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
> > path in two different branches)
> >
> > 4. compare any two arbitrary repos paths/revs
> > svn diff --old=url1[@REV] --new=url2[@REV]
> >
> > 5. compare a wc path to an arbitrary repos path
> > svn diff --old=url1[@REV] --new=path
>
> You'll get my +1 if you can write a clear, concise usage message.
> You'll get another one if you get to codin'. :-)
Yeah, I have to say, I give it a +1 as well. This is definitely the
Least Evil solution of all that have been brought up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> diff (di): display the differences between two paths[1].
> usage: 1. svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [PATH ...]
> 2. svn diff -r N[:M] URL
>
> 1. Displays the differences between OLD-TARGET and NEW-TARGET. If
> PATHs are given, displays only differences in those paths, relative
> to NEW-TARGET. OLD-TARGET and NEW-TARGET may be local wc path or
> URL[@REV]. OLD-TARGET defaults to "BASE", NEW-TARGET to ´.´
>
> '-r N' sets revision of OLD-TARGET to N. '-r N:M' also sets
> revision of NEW-TARGET to M.
>
> 2. Shorthand for 'svn diff -r N[:M] --old=URL --new=URL'.
>
> Use just 'svn diff' to display the local modifications in your wc.
Okay. You get my +1 now. Well done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > Greg Hudson <gh...@MIT.EDU> writes:
> >
> >> usage: 1. svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [PATH ...]
> >> 2. svn diff -r N[:M] URL
> > [...]
> >> Does anyone else want to have a crack at implementing this?
> >
> > Yes.
>
> It works. I'd like to add
>
> 3. svn diff URL1[@N] URL2[@M]
>
> Shorthand for 'svn diff [-rN[:M]] --old URL1 --new URL2'
> where N and M default to HEAD.
>
> The reason for this is so that I think there should be a diff command
> with the same syntax as the merge command
>
> svn merge URL1[@N] URL2[@M] path
>
> so that a user can preview the changes to be merged without having to
> "translate" the command.
I too think that merge and diff should have a matched syntax wherever
possible -- I never use merge without first "merging" to stdout ;-).
So there's two ways to go:
- add the @-syntax back to diff
- remove the @-syntax from merge
I've heard arguments for both ("keep the revision modifier with the
URL it modifies"; "gain '@' back as a character that is valid in paths
used with these functions"). I personally like the @-syntax, despite
the lossage, but I'll leave it to others to decide.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-05-22 at 20:46, Philip Martin wrote:
> 3. svn diff URL1[@N] URL2[@M]
No strong opinion. It's another special case, but your argument for it
makes sense.
I note that the new svn diff syntax can be used as a merge syntax, and
that would help with cherry-picking ("svn merge --old=branch-base-url
--new=branch-url file1 file2"), but it would certainly make the common
case more verbose. And we'd have to punt the destination wc argument,
forcing it to always be ".". Not very compelling.
(And, while I'm here: I think Sander's point is worrisome, but I'm not
sure whether it should deter us. Basically, the issue is this: when a
user runs "svn diff -r M:N foo bar", our new syntax interprets foo
relative to rev N of the current working directory, which is not
necessarily what a user would expect--especially if the user just ran
"svn log foo" and wanted to look at the changes between two revs of it.
There's no way to repair this problem without abandoning the principle
that "we're always comparing two things, possibly with path
restrictions." (The sever breakdown case is when the user runs "svn
diff -r N:M foo bar" and foo and bar were both renamed from disparate
parts of the tree.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Greg Hudson <gh...@MIT.EDU> writes:
>
>> usage: 1. svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [PATH ...]
>> 2. svn diff -r N[:M] URL
> [...]
>> Does anyone else want to have a crack at implementing this?
>
> Yes.
It works. I'd like to add
3. svn diff URL1[@N] URL2[@M]
Shorthand for 'svn diff [-rN[:M]] --old URL1 --new URL2'
where N and M default to HEAD.
The reason for this is so that I think there should be a diff command
with the same syntax as the merge command
svn merge URL1[@N] URL2[@M] path
so that a user can preview the changes to be merged without having to
"translate" the command.
It is possible to have a directory called 'http:', and so have a
working copy path called 'http:/foo', which could be written with an
additional directory separator as 'http://foo', and two such paths
would cause an URL to URL comparison rather than an iterative BASE to
working copy comparison. I don't see this a serious problem, it's no
worse than 'svn mkdir', and 'svn diff --old . http://foo http://bar'
would recover the iterative behaviour.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> usage: 1. svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [PATH ...]
> 2. svn diff -r N[:M] URL
[...]
> Does anyone else want to have a crack at implementing this?
Yes.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
cmpilato@collab.net writes:
> > These are not only two sets (which i found surprising), but they are
> > in the wrong order, which makes the composite patch unapplicable to
> > c@1 (which i think is a bug). Should I file this or go get some
> > sleep?
>
> Try 'svn diff -r 1 --ignore-ancestry c', and see if that helps.
Oh bummer. I tried it, and it made no difference to the recipe.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Jan Braun <ja...@gmx.de> writes:
> [1] While figuring that out, I stumbled about the following:
>
> svnadmin create repo
> svn co file://`pwd`/repo wc
> cd wc
> echo this is "c" in rev 1 >c
> echo this is "will-be-c" in rev 1 >willbec
> svn add willbec c
> svn ci -m "foo"
> svn rm c
> svn ci -m "bar"
> svn mv willbec c
> svn ci -m "baz"
> svn diff -r 1 c
>
> Index: c
> ===================================================================
> --- c (revision 1)
> +++ c (working copy)
> @@ -0,0 +1 @@
> +this is will-be-c in rev 1
> Index: c
> ===================================================================
> --- c (revision 1)
> +++ c (working copy)
> @@ -1 +0,0 @@
> -this is c in rev 1
>
> These are not only two sets (which i found surprising), but they are
> in the wrong order, which makes the composite patch unapplicable to
> c@1 (which i think is a bug). Should I file this or go get some
> sleep?
Try 'svn diff -r 1 --ignore-ancestry c', and see if that helps.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Jan Braun <ja...@gmx.de>.
Sander Striker wrote:
>
> > From: Greg Hudson [mailto:ghudson@MIT.EDU]
> > Sent: Tuesday, May 20, 2003 8:25 PM
> >
> > On Tue, 2003-05-20 at 13:52, Sander Striker wrote:
> > > Say that some file is called 'C' in my working copy. It was called 'B'
> > > in revision N and 'A' in revision M. Now, what would this do:
> > >
> > > svn diff --old=URL-OF-WC@M --new=URL-OF-WC@N A
>
> I had meant to say: svn diff --old=URL-OF-WC@M --new=URL-OF-WC@N C
> Where C is the file as currently in my working copy. Note that the
> shorthand of this makes the problem a bit clearer:
>
> svn diff -r M:N C
>
> So would my above example give me the diff between B@N and A@M, or would
> it try to do a diff between C@N and ... ?
"C" is interpreted relative to NEW-TARGET, thus it might be
1) between C@M and C@N or
2) between WILL-SOON-BE-RENAMED-TO-C@M and C@N
(...when i make up that there are C and WILL-SOON-BE-RENAMED-TO-C in
rev M, and C gets deleted and WILL-SOON-BE-RENAMED-TO-C moved to C
before rev N)
Currently, diff does 1), which is why I wrote "below (both) TARGETS"
in my proposal[1].
I'm rather confused now whether 2) could reasonably be implemented and
whether it'd be a good idea to do so...
Jan
[1] While figuring that out, I stumbled about the following:
svnadmin create repo
svn co file://`pwd`/repo wc
cd wc
echo this is "c" in rev 1 >c
echo this is "will-be-c" in rev 1 >willbec
svn add willbec c
svn ci -m "foo"
svn rm c
svn ci -m "bar"
svn mv willbec c
svn ci -m "baz"
svn diff -r 1 c
Index: c
===================================================================
--- c (revision 1)
+++ c (working copy)
@@ -0,0 +1 @@
+this is will-be-c in rev 1
Index: c
===================================================================
--- c (revision 1)
+++ c (working copy)
@@ -1 +0,0 @@
-this is c in rev 1
These are not only two sets (which i found surprising), but they are
in the wrong order, which makes the composite patch unapplicable to
c@1 (which i think is a bug). Should I file this or go get some sleep?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
"Sander Striker" <st...@apache.org> writes:
> > Does anyone else want to have a crack at implementing this? I feel like
> > my implementation effort would be better spent fixing bogons in ra_svn
> > (and making all the backward-incompatible changes while the user base is
> > still relatively low). If we can all agree on a syntax but no one wants
> > to implement it, we could file it away in the issue for later.
>
> I'm afraid we end up filing this in an issue. Not due to whether someone
> wants, but due to if someone wants and has the time.
Yeah. File an issue, schedule for Beta, and while you're at it, move
issue #1142 to Beta, too, as dependent upon your new issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Resolution of 'svn diff' change?
Posted by Sander Striker <st...@apache.org>.
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Tuesday, May 20, 2003 8:25 PM
> On Tue, 2003-05-20 at 13:52, Sander Striker wrote:
> > Say that some file is called 'C' in my working copy. It was called 'B'
> > in revision N and 'A' in revision M. Now, what would this do:
> >
> > svn diff --old=URL-OF-WC@M --new=URL-OF-WC@N A
I had meant to say: svn diff --old=URL-OF-WC@M --new=URL-OF-WC@N C
Where C is the file as currently in my working copy. Note that the
shorthand of this makes the problem a bit clearer:
svn diff -r M:N C
> I had proposed that paths are relative to new-target. Here is a usage
> message, adapted from Jan's, with a special case to preserve "svn diff
> -r N:M URL" as requested by Phillip. (I admit, that blows a hole in my
> "with no corner cases" assertion. But it's just a convenient shorthand
> for the normal use case. Another option would be to make an option
> which sets both OLD-TARGET and NEW-TARGET, which would allow for "svn
> diff -r N[:M] --fabledoption=TARGET path1 path2 ...". That really gets
> back into bikeshed-painting territory, though.)
>
> ---
> diff (di): display the differences between two paths[1].
> usage: 1. svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [PATH ...]
> 2. svn diff -r N[:M] URL
>
> 1. Displays the differences between OLD-TARGET and NEW-TARGET. If
> PATHs are given, displays only differences in those paths, relative
> to NEW-TARGET. OLD-TARGET and NEW-TARGET may be local wc path or
> URL[@REV]. OLD-TARGET defaults to "BASE", NEW-TARGET to ´.´
>
> '-r N' sets revision of OLD-TARGET to N. '-r N:M' also sets
> revision of NEW-TARGET to M.
>
> 2. Shorthand for 'svn diff -r N[:M] --old=URL --new=URL'.
>
> Use just 'svn diff' to display the local modifications in your wc.
> ---
So would my above example give me the diff between B@N and A@M, or would
it try to do a diff between C@N and ... ?
> Does anyone else want to have a crack at implementing this? I feel like
> my implementation effort would be better spent fixing bogons in ra_svn
> (and making all the backward-incompatible changes while the user base is
> still relatively low). If we can all agree on a syntax but no one wants
> to implement it, we could file it away in the issue for later.
I'm afraid we end up filing this in an issue. Not due to whether someone
wants, but due to if someone wants and has the time.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Resolution of 'svn diff' change?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-05-20 at 13:52, Sander Striker wrote:
> Say that some file is called 'C' in my working copy. It was called 'B'
> in revision N and 'A' in revision M. Now, what would this do:
>
> svn diff --old=URL-OF-WC@M --new=URL-OF-WC@N A
I had proposed that paths are relative to new-target. Here is a usage
message, adapted from Jan's, with a special case to preserve "svn diff
-r N:M URL" as requested by Phillip. (I admit, that blows a hole in my
"with no corner cases" assertion. But it's just a convenient shorthand
for the normal use case. Another option would be to make an option
which sets both OLD-TARGET and NEW-TARGET, which would allow for "svn
diff -r N[:M] --fabledoption=TARGET path1 path2 ...". That really gets
back into bikeshed-painting territory, though.)
---
diff (di): display the differences between two paths[1].
usage: 1. svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [PATH ...]
2. svn diff -r N[:M] URL
1. Displays the differences between OLD-TARGET and NEW-TARGET. If
PATHs are given, displays only differences in those paths, relative
to NEW-TARGET. OLD-TARGET and NEW-TARGET may be local wc path or
URL[@REV]. OLD-TARGET defaults to "BASE", NEW-TARGET to ´.´
'-r N' sets revision of OLD-TARGET to N. '-r N:M' also sets
revision of NEW-TARGET to M.
2. Shorthand for 'svn diff -r N[:M] --old=URL --new=URL'.
Use just 'svn diff' to display the local modifications in your wc.
---
Does anyone else want to have a crack at implementing this? I feel like
my implementation effort would be better spent fixing bogons in ra_svn
(and making all the backward-incompatible changes while the user base is
still relatively low). If we can all agree on a syntax but no one wants
to implement it, we could file it away in the issue for later.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Resolution of 'svn diff' change?
Posted by Sander Striker <st...@apache.org>.
> From: Jan Braun [mailto:janbraun@gmx.de]
> Sent: Tuesday, May 20, 2003 7:44 PM
> cmpilato@collab.net wrote:
> > [--old=/--new= diff syntax]
> > You'll get my +1 if you can write a clear, concise usage message.
> > You'll get another one if you get to codin'. :-)
>
> I'd like to see that syntax implemented, so I try getting your first
> +1:
>
> diff (di): display the differences between two paths[1].
> svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [FILES...]
>
> Displays the differences between OLD-TARGET and NEW-TARGET.
> If FILES are given, displays only differences in those files [2]
>
> ´-r N:M´ is a shorthand for ´--old=URL-OF-YOUR-WC@N
> --new=URL-OF-YOUR-WC@M´
>
> TARGETs can be local wc paths and repostiory URLs
> OLD-TARGET defaults to "BASE", NEW-TARGET to ´.´
> Thus ´svn diff´ in a wc shows your local modifications.
> [...more use cases?]
>
> [1] not sure about "paths" here. "entities"? "resources"?
> [2] add something to clarify FILES are living below (both) TARGETs?
Say that some file is called 'C' in my working copy. It was called 'B'
in revision N and 'A' in revision M. Now, what would this do:
svn diff --old=URL-OF-WC@M --new=URL-OF-WC@N A
Clearly A doesn't live under all TARGETs, in this case it could even
be absent in both.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Jan Braun <ja...@gmx.de>.
cmpilato@collab.net wrote:
> [--old=/--new= diff syntax]
> You'll get my +1 if you can write a clear, concise usage message.
> You'll get another one if you get to codin'. :-)
I'd like to see that syntax implemented, so I try getting your first
+1:
diff (di): display the differences between two paths[1].
svn diff [-r N[:M]] [--old=OLD-TARGET] [--new=NEW-TARGET] [FILES...]
Displays the differences between OLD-TARGET and NEW-TARGET.
If FILES are given, displays only differences in those files [2]
´-r N:M´ is a shorthand for ´--old=URL-OF-YOUR-WC@N
--new=URL-OF-YOUR-WC@M´
TARGETs can be local wc paths and repostiory URLs
OLD-TARGET defaults to "BASE", NEW-TARGET to ´.´
Thus ´svn diff´ in a wc shows your local modifications.
[...more use cases?]
[1] not sure about "paths" here. "entities"? "resources"?
[2] add something to clarify FILES are living below (both) TARGETs?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> > Ghudson, I think your proposal has some promise. But for those of us
> > who are a bit slow-witted, can you demonstrate how your --old/--new
> > diff syntax would be used to cover all five use-cases I outlined in
> > the earlier mail? Humour me... :-)
>
> 1. show local mods in a working copy
> svn diff
> (or: svn diff file1 file2 ..., if only for some files/dirs)
>
> 2. compare a wc path with a different version of itself
> svn diff -r M path
> (or: svn diff --old=url[@REV] path, to compare against a branch)
>
> 3. compare two specific versions of a wc path
> svn diff -r M:N path
> (or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
> path in two different branches)
>
> 4. compare any two arbitrary repos paths/revs
> svn diff --old=url1[@REV] --new=url2[@REV]
>
> 5. compare a wc path to an arbitrary repos path
> svn diff --old=url1[@REV] --new=path
You'll get my +1 if you can write a clear, concise usage message.
You'll get another one if you get to codin'. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Resolution of 'svn diff' change?
Posted by Sander Striker <st...@apache.org>.
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Tuesday, May 20, 2003 5:54 AM
> On Mon, 2003-05-19 at 23:36, Ben Collins-Sussman wrote:
>> Ghudson, I think your proposal has some promise. But for those of us
>> who are a bit slow-witted, can you demonstrate how your --old/--new
>> diff syntax would be used to cover all five use-cases I outlined in
>> the earlier mail? Humour me... :-)
>
> 1. show local mods in a working copy
> svn diff
> (or: svn diff file1 file2 ..., if only for some files/dirs)
>
> 2. compare a wc path with a different version of itself
> svn diff -r M path
> (or: svn diff --old=url[@REV] path, to compare against a branch)
>
> 3. compare two specific versions of a wc path
> svn diff -r M:N path
> (or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
> path in two different branches)
>
> 4. compare any two arbitrary repos paths/revs
> svn diff --old=url1[@REV] --new=url2[@REV]
>
> 5. compare a wc path to an arbitrary repos path
> svn diff --old=url1[@REV] --new=path
Nice. I like it. This gets my final +1. I was already prepared to go
for the two commands solution, but this is a lot better.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Ben Collins-Sussman <su...@collab.net>.
William Uther <wi...@cse.unsw.edu.au> writes:
> > 1. show local mods in a working copy
> > svn diff
> > (or: svn diff file1 file2 ..., if only for some files/dirs)
> >
> > 2. compare a wc path with a different version of itself
> > svn diff -r M path
> > (or: svn diff --old=url[@REV] path, to compare against a branch)
> >
> > 3. compare two specific versions of a wc path
> > svn diff -r M:N path
> > (or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
> > path in two different branches)
> >
> > 4. compare any two arbitrary repos paths/revs
> > svn diff --old=url1[@REV] --new=url2[@REV]
> >
> > 5. compare a wc path to an arbitrary repos path
> > svn diff --old=url1[@REV] --new=path
> >
>
> 6. compare a couple of files (file1 file2 file3) in two different
> branches (branch_url1 and branch_url2).
> svn diff --old=branch_url1[@REV] --new=branch_url2[@rev] file1
> file2 file3
Yeah, this is pretty nice stuff. Gee whiz.
> Does this also work as a merge syntax?
I don't think we need to change merge syntax at all. It takes exactly
3 arguments: source, source, target. End of story. There's no need
for --old and --new stuff, because we're not trying to create an
iterative syntax.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by William Uther <wi...@cse.unsw.edu.au>.
On Tuesday, May 20, 2003, at 01:53 PM, Greg Hudson wrote:
> On Mon, 2003-05-19 at 23:36, Ben Collins-Sussman wrote:
>> Luke Blanshard <lu...@blanshard.us> writes:
>>
>>> This seems like the clearest and simplest approach being tossed
>>> around. But it's not getting much attention. Why is that exactly?
>
> Probably because I injected it late in the thread.
>
>> Ghudson, I think your proposal has some promise. But for those of us
>> who are a bit slow-witted, can you demonstrate how your --old/--new
>> diff syntax would be used to cover all five use-cases I outlined in
>> the earlier mail? Humour me... :-)
>
> 1. show local mods in a working copy
> svn diff
> (or: svn diff file1 file2 ..., if only for some files/dirs)
>
> 2. compare a wc path with a different version of itself
> svn diff -r M path
> (or: svn diff --old=url[@REV] path, to compare against a branch)
>
> 3. compare two specific versions of a wc path
> svn diff -r M:N path
> (or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
> path in two different branches)
>
> 4. compare any two arbitrary repos paths/revs
> svn diff --old=url1[@REV] --new=url2[@REV]
>
> 5. compare a wc path to an arbitrary repos path
> svn diff --old=url1[@REV] --new=path
>
6. compare a couple of files (file1 file2 file3) in two different
branches (branch_url1 and branch_url2).
svn diff --old=branch_url1[@REV] --new=branch_url2[@rev] file1
file2 file3
Does this also work as a merge syntax?
Case 1 makes no sense as merge
Case 2 makes no sense as merge
Case 3 does make sense:
svn merge -r M:N path
(or: svn mer --old=url1[@REV] --new=url2[@REV] path, to compare
path in two different branches)
Compares the path [at the given revisions] and then merges the diff
into the current working copy
Case 4 does make sense
svn merge --old=url1[@REV] --new=url2[@REV]
Compares the two paths and merges the diff into the current working
copy
Case 5 makes no sense as merge
Case 6 does make sense
svn merge --old=branch_url1[@REV] --new=branch_url2[@rev] file1
file2 file3
Compares the supplied files from the two branches [at the given
revisions] and then merges the diff into the current working copy
Will :-}
--
Dr William Uther National ICT Australia
Phone: +61 2 9385 6926 School of Computer Science and
Engineering
Email: willu@cse.unsw.edu.au University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Monday, May 19, 2003, at 11:53 PM, Greg Hudson wrote:
> On Mon, 2003-05-19 at 23:36, Ben Collins-Sussman wrote:
>> Luke Blanshard <lu...@blanshard.us> writes:
>>
>>> This seems like the clearest and simplest approach being tossed
>>> around. But it's not getting much attention. Why is that exactly?
>
> Probably because I injected it late in the thread.
>
>> Ghudson, I think your proposal has some promise. But for those of us
>> who are a bit slow-witted, can you demonstrate how your --old/--new
>> diff syntax would be used to cover all five use-cases I outlined in
>> the earlier mail? Humour me... :-)
>
> 1. show local mods in a working copy
> svn diff
> (or: svn diff file1 file2 ..., if only for some files/dirs)
>
> 2. compare a wc path with a different version of itself
> svn diff -r M path
> (or: svn diff --old=url[@REV] path, to compare against a branch)
>
> 3. compare two specific versions of a wc path
> svn diff -r M:N path
> (or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
> path in two different branches)
>
> 4. compare any two arbitrary repos paths/revs
> svn diff --old=url1[@REV] --new=url2[@REV]
>
> 5. compare a wc path to an arbitrary repos path
> svn diff --old=url1[@REV] --new=path
I would prefer this over any solution that ends up with two diff
commands, it really seems like the 'right thing to do' in this case.
We get all the functionality, preserve the simple 'iterative' use case
people (myself included) like so much, and avoid that embarassing
discussion where we have to explain the difference between 'diff' and
'cmp'.
+1
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-05-19 at 23:36, Ben Collins-Sussman wrote:
> Luke Blanshard <lu...@blanshard.us> writes:
>
> > This seems like the clearest and simplest approach being tossed
> > around. But it's not getting much attention. Why is that exactly?
Probably because I injected it late in the thread.
> Ghudson, I think your proposal has some promise. But for those of us
> who are a bit slow-witted, can you demonstrate how your --old/--new
> diff syntax would be used to cover all five use-cases I outlined in
> the earlier mail? Humour me... :-)
1. show local mods in a working copy
svn diff
(or: svn diff file1 file2 ..., if only for some files/dirs)
2. compare a wc path with a different version of itself
svn diff -r M path
(or: svn diff --old=url[@REV] path, to compare against a branch)
3. compare two specific versions of a wc path
svn diff -r M:N path
(or: svn diff --old=url1[@REV] --new=url2[@REV] path, to compare
path in two different branches)
4. compare any two arbitrary repos paths/revs
svn diff --old=url1[@REV] --new=url2[@REV]
5. compare a wc path to an arbitrary repos path
svn diff --old=url1[@REV] --new=path
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Ben Collins-Sussman <su...@collab.net>.
Luke Blanshard <lu...@blanshard.us> writes:
> This seems like the clearest and simplest approach being tossed
> around. But it's not getting much attention. Why is that exactly?
Ghudson, I think your proposal has some promise. But for those of us
who are a bit slow-witted, can you demonstrate how your --old/--new
diff syntax would be used to cover all five use-cases I outlined in
the earlier mail? Humour me... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Luke Blanshard <lu...@blanshard.us>.
This seems like the clearest and simplest approach being tossed around.
But it's not getting much attention. Why is that exactly?
Greg Hudson wrote:
>On Mon, 2003-05-19 at 14:22, cmpilato@collab.net wrote:
>
>
>>Seriously, we could bat this issue around for weeks trying to make
>>diff do everything possible, but I think our only real responsibility
>>is to solve the most common use-cases without cutting off the ability
>>for folks to write scripts for their specific use-cases (that we don't
>>support directly).
>>
>>
>
>What's primarily nice about the "svn diff --old/--new" proposal is not
>that it has the extra functionality, but that it presents all of the
>requested diff operations in a single, relatively elegant framework with
>no edge cases. Sorry if I wasn't clear about that.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-05-19 at 14:22, cmpilato@collab.net wrote:
> Seriously, we could bat this issue around for weeks trying to make
> diff do everything possible, but I think our only real responsibility
> is to solve the most common use-cases without cutting off the ability
> for folks to write scripts for their specific use-cases (that we don't
> support directly).
What's primarily nice about the "svn diff --old/--new" proposal is not
that it has the extra functionality, but that it presents all of the
requested diff operations in a single, relatively elegant framework with
no edge cases. Sorry if I wasn't clear about that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> I do think folks should look at this seriously (unlike CMike's straw man
> with "svn diff --compare" followed by any even number of arguments), but
> I'm not 100% convinced that it's better than having an iterative "svn
> diff" and a comparative "svn compare" and just punting the "iterate
> within a comparison" functionality.
So ... if not 100%, then how much? :-)
Seriously, we could bat this issue around for weeks trying to make
diff do everything possible, but I think our only real responsibility
is to solve the most common use-cases without cutting off the ability
for folks to write scripts for their specific use-cases (that we don't
support directly).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-05-19 at 14:02, Scott Lamb wrote:
> On Monday, May 19, 2003, at 12:45 US/Central, Greg Hudson wrote:
>
> > svn diff [--old=old-target] [--new=new-target] [file1 file2 ...]
>
> Plus a [-r M[:N]], I assume?
Well, -r M would be shorthand for "--old=my-wc-url@M" and -r M:N would
be shorthand for --old=my-wc-url@M --new=my-wc-url@N. But yeah, we'd
probably have to allow them for ease of use.
I do think folks should look at this seriously (unlike CMike's straw man
with "svn diff --compare" followed by any even number of arguments), but
I'm not 100% convinced that it's better than having an iterative "svn
diff" and a comparative "svn compare" and just punting the "iterate
within a comparison" functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Scott Lamb <sl...@slamb.org>.
On Monday, May 19, 2003, at 12:45 US/Central, Greg Hudson wrote:
> svn diff [--old=old-target] [--new=new-target] [file1 file2 ...]
Plus a [-r M[:N]], I assume?
> Where a target is a wc path or url[@rev], and the file list is relative
> to new-target. old-target defaults to wc-base, new-target defaults to
> "." (meaning wc-current), and the file list also defaults to ".". I
> don't know if that would satisfy people today. svn compare would
> become
> "svn diff --old=foo --new=bar" with the implicit "." file list.
That's the first one I really like. It seems like it very naturally how
I use diff (like Justin's, but even more so - the repository I commit
the most to doesn't even have any branches/tags, so the most common
case is even more common). I think it supports everything anyone wants
to do, which none of the others can match. And the orthogonal
specification of target/file list with the default values really makes
clear what's going on. I think there would be a lot of confusion over
the exact difference between "diff" and "compare", especially since one
isn't a subset of the other (up/switch).
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Greg Hudson <gh...@MIT.EDU>.
I'm willing to accede to a new subcommand, but as Phillip notes:
* svn diff should take -r options.
* svn compare should demand two arguments.
I'll note that there is still a piece of functionality from CVS which
these two commands don't encompass, specifically "compare foo and bar
and baz from my working directory against the vendor branch". In CVS,
that's "cvs diff -r vendor foo bar baz"; in svn, we would need a way to
say "svn compare vendor-url . foo bar baz" or something like that. In
one of the long-ago debates, I proposed a unified syntax which would
handle it.
svn diff [--old=old-target] [--new=new-target] [file1 file2 ...]
Where a target is a wc path or url[@rev], and the file list is relative
to new-target. old-target defaults to wc-base, new-target defaults to
"." (meaning wc-current), and the file list also defaults to ".". I
don't know if that would satisfy people today. svn compare would become
"svn diff --old=foo --new=bar" with the implicit "." file list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Resolution of 'svn diff' change?
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Monday, May 19, 2003 7:06 PM
[...]
> The proposal from cmpilato, which I like, is to make 'svn diff' cover
> only use-case 1. That use-case is what users need 80% of the time.
> A new 'svn compare' subcommand would cover cases 2-5, and be somewhat
> complex, but no worse than the status quo.
Fair enough. +1.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> My next instructions were to sell the community on the two-subcommand
> proposition. :-) (Gee, thanks, Ben)
Here's how I see it. We have the following use-cases to cover:
1. show local mods in a working copy
2. compare a wc path with a different version of itself
3. compare two specific versions of a wc path
4. compare any two arbitrary repos paths/revs
Up till now, we've designed 'svn diff' to have many different syntaxes
and options to cover these cases:
1. svn diff .
svn diff file1 file2 file3 [...]
2. svn diff -r178 foo.c
3. svn diff -r122:178 foo.c
4. svn diff URL1@150 URL2@200
If you ask me, this current 'svn diff' is already really complicated.
And now, with issue #1142, the dam has broken open. We need to add
this use-case:
5. compare a wc path to an arbitrary repos path
This new requirement pretty much contradicts the iterative syntax of
use-case #1.
So as cmpilato says, we can either find a new way to get 'svn diff' to
cover use-case 5... perhaps by a new option. But then I think we end
up tottering on making 'svn diff' completely incomprehensible and
unusable.
Yes, new subcommands are generally bad things. We, as a group of
developers, have always shied away from it. But now we're faced with
choosing between two evils: a new subcommand, or a single subcommand
that is impossibly, unusably overloaded.
The proposal from cmpilato, which I like, is to make 'svn diff' cover
only use-case 1. That use-case is what users need 80% of the time.
A new 'svn compare' subcommand would cover cases 2-5, and be somewhat
complex, but no worse than the status quo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Philip Martin <ph...@codematters.co.uk>.
cmpilato@collab.net writes:
> Ben seemed convinced, but asked for those two usage messages. Here
> they are:
>
> $ svn help compare
> compare (cmp): display the differences between two paths.
> usage: 1. compare [-r N[:M]] [TARGET]
> 2. compare TARGET1[@N] TARGET2[@M]
>
> Display the differences between two targets (one of which may be implied)
> in a format suitable for use with most 'patch' programs.
>
> 1. In the first syntax, TARGET is either a working copy path
> or URL. If no TARGET is specified, a value of '.' is assumed.
> Use the -r option to specify revision ranges -- if TARGET is a
> URL, this defaults to HEAD:PREV; if TARGET is a working copy
> path, the default is to display local modifications.
>
> 2. If the alternate syntax is used, TARGET1 and TARGET2
> (perhaps at specified revisions N and M, respectively) will
> be compared against each other.
I'd prefer it if the compare command did not support implied
targets. That makes it more obvious that two arguments are required,
and that they get compared.
>
> $ svn help diff
> diff (di): display local working copy modifications
> usage: diff [WC-PATH ...]
>
> Display uncommitted modifications made to working copy targets in a
> format suitable for use with most 'patch' programs.
I'd prefer it if the diff command accepted [-r N[:M]]. The diff
command will do all the comparisons, except those that involve
comparing two targets against each other. The compare command handles
the latter case.
If we take your proposal without change then we lose some of the
current functionality, it is not possible to do
svn diff -rN:M wc/foo.c wc/bar.c
It doesn't make sense to introduce a new command and lose
functionality.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
cmpilato@collab.net writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > cmpilato@collab.net writes:
> >
> > > "Sander Striker" <st...@apache.org> writes:
> > >
> > > > > where (2a) is the only truly sensible decision in my mind.
> > > >
> > > > Oof...
> > >
> > > Yeah. "Only truly sensible" given the base assumption that the
> > > iterative case is truly necessary. I've not fallen to that assumption
> > > yet. :-)
> >
> > Yeah, I'm failing to understand why people need 'svn diff' to default
> > to the iterative case. Justin and Colin have said that the iterative
> > use-case is a part of their "basic svn work-cycle", and Justin said he
> > "often has multiple changesets" in his working copy.
> >
> > (Yikes, this mail is staring to read like a Zagat Restaurant review!)
> >
> > This is not a dig against anybody's work habits... but do you really
> > maintain mulitple changesets in a working-copy? How do you deal with
> > that? I've been there, and it's always such a mess. When I encounter
> > a bug, I never know if it's because of one changeset or another --
> > there are too many changed variables to isolate the problem.
>
> Oh...hmm. You know, I keep multiple changesets in my WC all the
> time. As of a few minutes ago, there was:
>
> 1. new diff syntax
> 2. issue #1015
> 3. the svndumpfilter copy-n-pasto bug
>
> The fact is that unless one changeset overlaps files with another, or
> endangers the testing of another, I have no problems keeping up with a
> few different sets. And now that I think about it, I use the
> iterative diff sometimes (not always -- if my brain is smart enough to
> remember which paths to diff, it's smart enough to remember which
> paths to ignore when I do 'svn diff' from the top of my tree).
>
> --
>
> I'm all for providing all the functionality we can, as long as we
> don't make the UI so cloudy as to be worthless. I really think that
> we can please everyone with 'svn diff' iteratively doing BASE:WORK,
> and 'svn compare (cmp)' doing the more complex work. And I can have
> it all coded up in a couple of hours -- the "new diff syntax" is done,
> sitting as local mods in my working copy ... changeset #1 :-)
So in a private conversation, Ben drilled me on why I would want a new
subcommand over just a --compare flag to diff.
1. 'svn diff' run in the working copy is by and large the lion's
share of uses for this subcommand. It was the original
implementation, on which was later added support for URL-ish and
--revision-ish things.
2. I'd always rather have two clear, concise usage messages for
individual subcommands than one subcommand whose usage message is
so complicated by special-case options and flags that it's
impossible to understand. 'svn diff' is *already* too
complicated to understand, and we're talking about added a flag
that changes the core of the way the arguments are intepreted?
Gimme a friggin' break.
Ben seemed convinced, but asked for those two usage messages. Here
they are:
$ svn help compare
compare (cmp): display the differences between two paths.
usage: 1. compare [-r N[:M]] [TARGET]
2. compare TARGET1[@N] TARGET2[@M]
Display the differences between two targets (one of which may be implied)
in a format suitable for use with most 'patch' programs.
1. In the first syntax, TARGET is either a working copy path
or URL. If no TARGET is specified, a value of '.' is assumed.
Use the -r option to specify revision ranges -- if TARGET is a
URL, this defaults to HEAD:PREV; if TARGET is a working copy
path, the default is to display local modifications.
2. If the alternate syntax is used, TARGET1 and TARGET2
(perhaps at specified revisions N and M, respectively) will
be compared against each other.
$ svn help diff
diff (di): display local working copy modifications
usage: diff [WC-PATH ...]
Display uncommitted modifications made to working copy targets in a
format suitable for use with most 'patch' programs.
My next instructions were to sell the community on the two-subcommand
proposition. :-) (Gee, thanks, Ben)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log: date and time with --xml
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> My guess would be that the XML format is supposed to be easily
> parseable, so it uses the raw timestamp that comes from the repo. "svn
> log", on the other hand, munges the timestamp into our human-readable
> format, which uses local time by default. And I think the current
> behaviour is correct. It is not "you" who must know the UTC offset, it
> is whichever program is parsing the XML.
Yes. In fact, now that you mention it, I think that was our reasoning
at the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tag: format and timezone
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>>>2. Do I always get back the UTC time in the <date> tag?
>>>
>>>
>>The time zone indicator is part of the time format, so you can determine
>>the UTC offset by parsing the timestamp.
>>
>>
>
>If that's the case, which portion of the above timestamp indicates the
>time zone? I think the "Z" indicates UTC?
>
Yes, 'Z' is the same as UTC+00:00. It's a symbold for the military
"Zulu" or "zero" time zone. A-M indicate positive offsets, N-X indicate
negative iffsets from UTC (in 1-hour increments). 'Z' is explicitly
allowed by ISO-8601 -- it's a handy shorthand for UTC.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tag: format and timezone
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> >1. I am not sure what mean the numbers after the 42 seconds...
> ><date>2003-04-30T10:01:42.349105Z</date>
>
> Numbers after a decimal point are usually called a "fraction". In this
> case, since there are six numbers, they indicate millionths of a second,
> also called "microseconds".
I think it was the "Z" that threw him off.
Nonetheless, I laughed out loud at your response :-).
> >2. Do I always get back the UTC time in the <date> tag?
>
> The time zone indicator is part of the time format, so you can determine
> the UTC offset by parsing the timestamp.
If that's the case, which portion of the above timestamp indicates the
time zone? I think the "Z" indicates UTC? (Had this been 'svn log'
instead of 'svn log --xml', *then* the timestamp would clearly
indicate an offset from UTC. Excuse me, I mean Greenwich Mean Time.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tag: format and timezone
Posted by Branko Čibej <br...@xbc.nu>.
etienne studer wrote:
>Hi
>
>1. I am not sure what mean the numbers after the 42 seconds...
><date>2003-04-30T10:01:42.349105Z</date>
>
Numbers after a decimal point are usually called a "fraction". In this
case, since there are six numbers, they indicate millionths of a second,
also called "microseconds".
>2. Do I always get back the UTC time in the <date> tag?
>
The time zone indicator is part of the time format, so you can determine
the UTC offset by parsing the timestamp.
>I appreciate your help.
>
>Best regards, Etienne
>
>
>
>
>>-----Original Message-----
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Montag, 19. Mai 2003 20:15
>>To: kfogel@collab.net
>>Cc: etienne studer; dev@subversion.tigris.org
>>Subject: Re: svn log: date and time with --xml
>>
>>
>>kfogel@collab.net wrote:
>>
>>
>>
>>>"etienne studer" <et...@canoo.com> writes:
>>>
>>>
>>>
>>>
>>>>Using 'svn log' without '--xml' gives me the correct time.
>>>>
>>>>
>>Using 'svn log'
>>
>>
>>>>with '--xml' gives me the GMT time. Does this mean that when
>>>>
>>>>
>>using the xml
>>
>>
>>>>format I have to know how many hours I am off GMT? Or is there
>>>>
>>>>
>>another way
>>
>>
>>>>how to get the local time?
>>>>
>>>>Using 'svn log' without the '--xml' option returns
>>>>'...2003-02-24 17:35:24 +0100...'. -> correct
>>>>
>>>>Using 'svn log' with the '--xml' option returns
>>>>'<date>2003-02-24T16:35:24.120656Z</date>' -> one hour off
>>>>
>>>>
>>>>
>>>>
>>>I think so -- there's no "--local-time" option.
>>>
>>>But, I wonder why we use GMT for one and localtime for the other?...
>>>
>>>
>>>
>>>
>>My guess would be that the XML format is supposed to be easily
>>parseable, so it uses the raw timestamp that comes from the repo. "svn
>>log", on the other hand, munges the timestamp into our human-readable
>>format, which uses local time by default. And I think the current
>>behaviour is correct. It is not "you" who must know the UTC offset, it
>>is whichever program is parsing the XML.
>>
>>--
>>Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
>>
>>
>>
>>
>
>
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
tag: format and timezone
Posted by etienne studer <et...@canoo.com>.
Hi
1. I am not sure what mean the numbers after the 42 seconds...
<date>2003-04-30T10:01:42.349105Z</date>
2. Do I always get back the UTC time in the <date> tag?
I appreciate your help.
Best regards, Etienne
> -----Original Message-----
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Montag, 19. Mai 2003 20:15
> To: kfogel@collab.net
> Cc: etienne studer; dev@subversion.tigris.org
> Subject: Re: svn log: date and time with --xml
>
>
> kfogel@collab.net wrote:
>
> >"etienne studer" <et...@canoo.com> writes:
> >
> >
> >>Using 'svn log' without '--xml' gives me the correct time.
> Using 'svn log'
> >>with '--xml' gives me the GMT time. Does this mean that when
> using the xml
> >>format I have to know how many hours I am off GMT? Or is there
> another way
> >>how to get the local time?
> >>
> >>Using 'svn log' without the '--xml' option returns
> >>'...2003-02-24 17:35:24 +0100...'. -> correct
> >>
> >>Using 'svn log' with the '--xml' option returns
> >>'<date>2003-02-24T16:35:24.120656Z</date>' -> one hour off
> >>
> >>
> >
> >I think so -- there's no "--local-time" option.
> >
> >But, I wonder why we use GMT for one and localtime for the other?...
> >
> >
> My guess would be that the XML format is supposed to be easily
> parseable, so it uses the raw timestamp that comes from the repo. "svn
> log", on the other hand, munges the timestamp into our human-readable
> format, which uses local time by default. And I think the current
> behaviour is correct. It is not "you" who must know the UTC offset, it
> is whichever program is parsing the XML.
>
> --
> Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log: date and time with --xml
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>"etienne studer" <et...@canoo.com> writes:
>
>
>>Using 'svn log' without '--xml' gives me the correct time. Using 'svn log'
>>with '--xml' gives me the GMT time. Does this mean that when using the xml
>>format I have to know how many hours I am off GMT? Or is there another way
>>how to get the local time?
>>
>>Using 'svn log' without the '--xml' option returns
>>'...2003-02-24 17:35:24 +0100...'. -> correct
>>
>>Using 'svn log' with the '--xml' option returns
>>'<date>2003-02-24T16:35:24.120656Z</date>' -> one hour off
>>
>>
>
>I think so -- there's no "--local-time" option.
>
>But, I wonder why we use GMT for one and localtime for the other?...
>
>
My guess would be that the XML format is supposed to be easily
parseable, so it uses the raw timestamp that comes from the repo. "svn
log", on the other hand, munges the timestamp into our human-readable
format, which uses local time by default. And I think the current
behaviour is correct. It is not "you" who must know the UTC offset, it
is whichever program is parsing the XML.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log: date and time with --xml
Posted by kf...@collab.net.
"etienne studer" <et...@canoo.com> writes:
> Using 'svn log' without '--xml' gives me the correct time. Using 'svn log'
> with '--xml' gives me the GMT time. Does this mean that when using the xml
> format I have to know how many hours I am off GMT? Or is there another way
> how to get the local time?
>
> Using 'svn log' without the '--xml' option returns
> '...2003-02-24 17:35:24 +0100...'. -> correct
>
> Using 'svn log' with the '--xml' option returns
> '<date>2003-02-24T16:35:24.120656Z</date>' -> one hour off
I think so -- there's no "--local-time" option.
But, I wonder why we use GMT for one and localtime for the other?...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
svn log: date and time with --xml
Posted by etienne studer <et...@canoo.com>.
Hi
First, congrats to Subversion! We use it with pleasure for several months
now.
A question:
Using 'svn log' without '--xml' gives me the correct time. Using 'svn log'
with '--xml' gives me the GMT time. Does this mean that when using the xml
format I have to know how many hours I am off GMT? Or is there another way
how to get the local time?
Using 'svn log' without the '--xml' option returns
'...2003-02-24 17:35:24 +0100...'. -> correct
Using 'svn log' with the '--xml' option returns
'<date>2003-02-24T16:35:24.120656Z</date>' -> one hour off
Thanks for your help, Etienne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> cmpilato@collab.net writes:
>
> > "Sander Striker" <st...@apache.org> writes:
> >
> > > > where (2a) is the only truly sensible decision in my mind.
> > >
> > > Oof...
> >
> > Yeah. "Only truly sensible" given the base assumption that the
> > iterative case is truly necessary. I've not fallen to that assumption
> > yet. :-)
>
> Yeah, I'm failing to understand why people need 'svn diff' to default
> to the iterative case. Justin and Colin have said that the iterative
> use-case is a part of their "basic svn work-cycle", and Justin said he
> "often has multiple changesets" in his working copy.
>
> (Yikes, this mail is staring to read like a Zagat Restaurant review!)
>
> This is not a dig against anybody's work habits... but do you really
> maintain mulitple changesets in a working-copy? How do you deal with
> that? I've been there, and it's always such a mess. When I encounter
> a bug, I never know if it's because of one changeset or another --
> there are too many changed variables to isolate the problem.
Oh...hmm. You know, I keep multiple changesets in my WC all the
time. As of a few minutes ago, there was:
1. new diff syntax
2. issue #1015
3. the svndumpfilter copy-n-pasto bug
The fact is that unless one changeset overlaps files with another, or
endangers the testing of another, I have no problems keeping up with a
few different sets. And now that I think about it, I use the
iterative diff sometimes (not always -- if my brain is smart enough to
remember which paths to diff, it's smart enough to remember which
paths to ignore when I do 'svn diff' from the top of my tree).
--
I'm all for providing all the functionality we can, as long as we
don't make the UI so cloudy as to be worthless. I really think that
we can please everyone with 'svn diff' iteratively doing BASE:WORK,
and 'svn compare (cmp)' doing the more complex work. And I can have
it all coded up in a couple of hours -- the "new diff syntax" is done,
sitting as local mods in my working copy ... changeset #1 :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> "Sander Striker" <st...@apache.org> writes:
>
> > > where (2a) is the only truly sensible decision in my mind.
> >
> > Oof...
>
> Yeah. "Only truly sensible" given the base assumption that the
> iterative case is truly necessary. I've not fallen to that assumption
> yet. :-)
Yeah, I'm failing to understand why people need 'svn diff' to default
to the iterative case. Justin and Colin have said that the iterative
use-case is a part of their "basic svn work-cycle", and Justin said he
"often has multiple changesets" in his working copy.
(Yikes, this mail is staring to read like a Zagat Restaurant review!)
This is not a dig against anybody's work habits... but do you really
maintain mulitple changesets in a working-copy? How do you deal with
that? I've been there, and it's always such a mess. When I encounter
a bug, I never know if it's because of one changeset or another --
there are too many changed variables to isolate the problem.
So when I need to switch tasks mid-stream, I'll run
$ svn diff > task1.patch
$ svn revert . -R
$ patch -p0 < task2.patch
And as a result, I almost never run 'svn diff' on a list of
targets... I either want to look at changes to a single file, or look
at the whole set of changes within '.'
Justin, or someone else, can you talk more about why the iterative
'svn diff' usage is important to you? I'm trying to stand in your
shoes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
"Sander Striker" <st...@apache.org> writes:
> > where (2a) is the only truly sensible decision in my mind.
>
> Oof...
Yeah. "Only truly sensible" given the base assumption that the
iterative case is truly necessary. I've not fallen to that assumption
yet. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Resolution of 'svn diff' change?
Posted by Sander Striker <st...@apache.org>.
> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> Sent: Monday, May 19, 2003 3:37 PM
[...]
> 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,
*mumble mumble*
> 2. then, either:
>
> a. add a new 'svn compare' subcommand to handle the 2-target
> comparitive diff case, or
The joy of another subcommand?
> 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".
-1. Telling people to run 'merge --dry-run' when what they want is
a diff (which they do not intend to merge at any point in time), is
counterintuitive.
> where (2a) is the only truly sensible decision in my mind.
Oof...
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? And next, how large is the pro-iterative camp?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Resolution of 'svn diff' change?
Posted by cm...@collab.net.
Justin Erenkrantz <ju...@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
Re: Resolution of 'svn diff' change?
Posted by Colin Watson <cj...@flatline.org.uk>.
On Mon, May 19, 2003 at 12:42:08AM -0700, Justin Erenkrantz wrote:
> 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? I'm not
> really clear what the resolution was with that thread as it went off in a
> million tangents. So, pardon my request for clarification.
>
> IMHO, this is *very* useful when you have local changes that you haven't
> committed and only want a partial 'diff' subset of a directory. I use it
> as:
>
> svn diff dir/x dir/y | less
Ugh, damn, yes. I didn't notice this in the original thread. This is
part of my basic work cycle with Subversion, and something I definitely
expect svn diff to provide ...
--
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
RE: Resolution of 'svn diff' change?
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:justin@erenkrantz.com]
> Sent: Monday, May 19, 2003 9:42 AM
And we were so close to consensus...
> 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.
Hmmm... it probably will give you the diff between dir/x and dir/y ;).
> Is that correct? I'm not really
> clear what the resolution was with that thread as it went off in a million
> tangents. So, pardon my request for clarification.
You go diving head first in that mail archive ;) :)
> IMHO, this is *very* useful when you have local changes that you haven't
> committed and only want a partial 'diff' subset of a directory. I use it as:
>
> svn diff dir/x dir/y | less
>
> to review my local changes where dir/z is also modified and I don't want to
> see its diff output (and ignoring it if it is present in the diff makes it too
> hard to review). Am I now going to have to do:
>
> svn diff dir/x >1
> svn diff dir/y >>1
> less 1
>
> or
>
> for i in dir/x dir/y; do svn diff $i | less; done
or, create a small wrapper that does this for you...
> whereas
>
> svn ci dir/x dir/y
>
> would still work as expected?
Yes. Well, that depends on your interpretation of expected.
> (Or, will commit reject the iterative case too?)
> 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.)
Urf... enter bikeshed.
> If the iterative case is indeed removed as I describe above, then I'm going to
> seriously contemplate vetoing any change to the 'svn diff' interface that
> removes the iterative case.
Not the veto card :(.
"I hereby consider vetoing the painting of any bikeshed purple."
> It's going to be extremely annoying working
> around this when I have lots of local mods in my working copy (which is gonna
> happen more than I'd like to admit - it's a frequent occurrence in
> httpd-land).
And this seems to be the main problem. And until you can work on a local branch,
or, have the ability to mark some changes as to-be-ignored, this will be a problem.
But, we all know that is post-1.0 material.
> Not to mention that this would be a significant regression from
> CVS with no clean alternative proposed by SVN.
I guess I never encounter this because I don't have mixed changesets in one
working copy. Would an --iterative switch help?
> Sorry for the late entry into this thread, but I'm slowly trying to catch up
> on this list after being away. -- justin
*tsk* *tsk* Oh well, I guess we have to blame Sony...
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org