You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Brian Denny <br...@briandenny.net> on 2004/04/08 13:54:55 UTC
Re: Oddity with svn diff on moved/renamed files.
On Thu, Apr 08, 2004 at 04:16:38PM -0500, Ben Collins-Sussman wrote:
>
> This is a tricky UI problem. On the one hand, the "A +" isn't really
> new, it's a copy. So if the user is running 'svn diff' in order to
> examine local mods before committing, the current behavior makes sense.
I don't get this. For an atomic 'svn mv', i suppose it would make sense.
But for a copy? It's a new file. Just because it has history...
Oh, now I get it. It has a history, and the difference between the
current state and the previous state in the history is "nothing".
> Any ideas about how to satisfy *both* use cases?
Another way of looking at the problem is: From the perspective of the
added-with-history file, no lines have been added/changed; but from the
perspective of the whole working copy, a bunch of lines (the new copy)
have been added.
So I'd say what we need is a patch format which can express the idea of
copy-with-history. :-)
Meantime, my vote is to generate the add-diff. We're all so used to
tools which *don't* follow copy history that it's not hard to ignore
that output if it's irrelevant to your use case. If you want a patch,
OTOH, it's very necessary.
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Travis P <sv...@castle.fastmail.fm>.
On Apr 9, 2004, at 6:22 PM, Greg Hudson wrote:
> On Fri, 2004-04-09 at 09:29, kfogel@collab.net wrote:
>> That option could simply by "-q", by the way, which is not used by
>> 'svn diff' right now.
>
> I don't like that idea. -q is normally about suppressing some kind of
> meta-output, not about displaying less of the usual kind of output.
Greg's thought was similar to my own reaction.
Maybe "--patch" to trigger a patch-compatible diff?
Just a thought.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> On Fri, 2004-04-09 at 09:29, kfogel@collab.net wrote:
> > That option could simply by "-q", by the way, which is not used by
> > 'svn diff' right now.
>
> I don't like that idea. -q is normally about suppressing some kind of
> meta-output, not about displaying less of the usual kind of output.
There's some precedent with 'svn log -q', at least.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-04-09 at 19:58, Ben Collins-Sussman wrote:
> We could go the other way. Make 'svn diff' default to what it does now,
> (which is optimized for the use case of "I want to see my local mods")
> and make 'svn diff -v' add extra verbose information for patches: files
> with status "A +" are shown in their entirety, just like status "A"
> files. Is that more reasonable?
I wouldn't object to that. (I'm not saying I would object to various
other proposals either, as long as they don't key off of -q.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson wrote:
> On Fri, 2004-04-09 at 09:29, kfogel@collab.net wrote:
>
>>That option could simply by "-q", by the way, which is not used by
>>'svn diff' right now.
>
>
> I don't like that idea. -q is normally about suppressing some kind of
> meta-output, not about displaying less of the usual kind of output.
We could go the other way. Make 'svn diff' default to what it does now,
(which is optimized for the use case of "I want to see my local mods")
and make 'svn diff -v' add extra verbose information for patches: files
with status "A +" are shown in their entirety, just like status "A"
files. Is that more reasonable?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-04-09 at 09:29, kfogel@collab.net wrote:
> That option could simply by "-q", by the way, which is not used by
> 'svn diff' right now.
I don't like that idea. -q is normally about suppressing some kind of
meta-output, not about displaying less of the usual kind of output.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by kf...@collab.net.
Bas Mevissen <ml...@basmevissen.nl> writes:
> 3) Having both plus and minus is needed for a good diff and will not
> disturd the human raeding back his changes too much.
>
> So I would propose to have both + and - by default and the option to
> switch them off both and replace them by the comment line as prosed at
> the second ).
That option could simply by "-q", by the way, which is not used by
'svn diff' right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Bas Mevissen <ml...@basmevissen.nl>.
Ben Collins-Sussman wrote:
>
> But what about the use case of just wanting to see your local mods? My
> impression is that people run 'svn diff' for that purpose much more
> often than they run 'svn diff' to generate a patch. I certainly do.
>
> I don't think we should completely toss one use-case away. The status
> quo breaks the ability to create patches, and your proposal breaks the
> ability to see local mods.
>
> I guess what I was thinking was (maybe?) we choose a default behavior,
> and add some sort of new option to 'svn diff' that toggles the other
> behavior. Is that crazy?
>
OK, some thoughts:
1) The current behaviour of only showing the minus (with the option to
hide it) is neither fish nor fowl. I think this is a bad default.
2) Using svn diff for showing local mods is imcomplete now. Because you
want to see that you have moved/renamed a file, even if you haven't
modified it. I would propose to add some diff-comment like "foo.c got
renamed to bar.c" to the output.
3) Having both plus and minus is needed for a good diff and will not
disturd the human raeding back his changes too much.
So I would propose to have both + and - by default and the option to
switch them off both and replace them by the comment line as prosed at
the second ).
BTW. how does svn diff behave when you use an external diff program?
Bas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Brian Denny <br...@briandenny.net>.
On Fri, Apr 09, 2004 at 07:59:39AM -0500, Ben Collins-Sussman wrote:
>
> But what about the use case of just wanting to see your local mods? My
> impression is that people run 'svn diff' for that purpose much more
> often than they run 'svn diff' to generate a patch. I certainly do.
>
> I don't think we should completely toss one use-case away. The status
> quo breaks the ability to create patches, and your proposal breaks the
> ability to see local mods.
I guess I don't see it as tossing a use case away, because I think it
actually makes sense to show the diff even in the use case we're talking
about. I can see it your way too, if I think about it, but intuitively,
in my head, if I want to "see local mods", and a file has been added in
my WC, with or without history, that's a local mod and I want to see it
when I run 'svn diff'.
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Ben Collins-Sussman <su...@collab.net>.
Bas Mevissen wrote:
> Brian Denny wrote:
>
>> Meantime, my vote is to generate the add-diff. We're all so used to
>> tools which *don't* follow copy history that it's not hard to ignore
>> that output if it's irrelevant to your use case. If you want a patch,
>> OTOH, it's very necessary.
>>
>
> That's my vote too. I don't think it will break anything when this
> becomes the default behaviour of svn diff.
But what about the use case of just wanting to see your local mods? My
impression is that people run 'svn diff' for that purpose much more
often than they run 'svn diff' to generate a patch. I certainly do.
I don't think we should completely toss one use-case away. The status
quo breaks the ability to create patches, and your proposal breaks the
ability to see local mods.
I guess what I was thinking was (maybe?) we choose a default behavior,
and add some sort of new option to 'svn diff' that toggles the other
behavior. Is that crazy?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Oddity with svn diff on moved/renamed files.
Posted by Bas Mevissen <ml...@basmevissen.nl>.
Brian Denny wrote:
> Meantime, my vote is to generate the add-diff. We're all so used to
> tools which *don't* follow copy history that it's not hard to ignore
> that output if it's irrelevant to your use case. If you want a patch,
> OTOH, it's very necessary.
>
That's my vote too. I don't think it will break anything when this
becomes the default behaviour of svn diff.
Bas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org