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

Re: svn commit: r966822 - in /subversion/trunk/subversion: libsvn_client/repos_diff.c tests/cmdline/merge_tests.py

From: Stephen Butler <sbutler_at_elego.de>
Date: Mon, 16 Aug 2010 11:23:35 +0200

On Aug 16, 2010, at 10:40 , Julian Foad wrote:

> On Thu, 2010-08-12, Paul Burba wrote:
>> ### Check diff --summarize for r2
>>> svn diff -r1:2 --summarize
>> AM nu
>> AM J
>> Should we really be describing the props for this added (not copied!)
>> file as modified? It seems incorrect to call the props modified in
>> this case. I ask because this is one of the problems I am running
>> into with fixing this issue in mod_dav_svn, and before I spend more
>> time trying to "fix" it I want to be sure the current behavior is
>> really what we expect.
>> Paul "Dying slowly at the hands of mod_dav_svn" Burba
> I would suggest that the output of "svn diff --summarize" should be
> consistent with the likes of "svn add" (no 'M'), "svn status" (no 'M')
> and "svn update" (I haven't checked this one).

Fixed in r985735, while I was working on issue #2333 "svn diff URL1
URL2 != svn diff URL2 URL1".

Strangely, the 'AM' output occurred only via ra_svn and ra_file, not
via ra_dav. But I guess that's not strange to anyone following this

The bug occurs in 1.6, too. We never tested '--summarize' properly.

My fix is a simple hack in libsvn_client/repos_diff_summarize.c, but
quite similar to some longstanding hacks in libsvn_client/repos_diff.c.
If that makes any sense....


Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2010-08-16 11:24:21 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.