On Tue, Jun 25, 2013 at 11:35 PM, Ben Reser <ben_at_reser.org> wrote:
> On Tue, Jun 25, 2013 at 11:29 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> Wow, wait a minute. Are you suggesting removing the (existing)
>> diff-copy-from option from 'svnlook diff'? Why? What's wrong with it?
>> It provides very useful functionality. I definitely use it for
>> post-commit mails, because it makes them much more focused on the
>> interesting diff portion. It's very clear in what it does, and it does
>> it well :-).
> No, I didn't realize that it already existed, thought you were
> proposing to add it.
>> I see no inconsistency here. 'svnlook diff' simply has an option (a
>> very good one IMHO) that 'svn diff' doesn't have. And that option
>> happens to solve the issue at hand (albeit only for svnlook right now,
>> not for svn).
> Yeah, in that case we ought to just add the option --diff-copy-from to
> svn. --git should imply the --diff-copy-from option, since we should
> represent the copies as extended headers.
While we're on the subject, I'd like to point to a post from half a
year ago, where I listed some of the inconsistencies between 'svnlook
diff' and 'svn diff':
(part of a thread started as "Re: multiple targets for 'svnlook
propget'", but Julian then re-subjected to "'svn diff' vs 'svnlook
diff'" when he replied)
In that post I thought that --show-copies-as-adds (svn) was the
reverse from --diff-copy-from (svnlook), but I observed that it didn't
"However, I just
quickly tested an 'svn diff -c XXX' of some revision which has a move,
and it always shows the moved file in full as a delete and an add, no
matter if I use --show-copies-as-adds or not. So it seems that
detecting copies with their sources is broken in 'svn diff'. "
Funny to read that back now :-).
Received on 2013-06-25 23:56:08 CEST