Madan U Sreenivasan wrote:
> On Fri, 07 Jul 2006 14:12:21 +0530, Kamesh Jayachandran
> <kamesh@collab.net> wrote:
>
>> Madan U Sreenivasan wrote:
> [snip]
>>> 1) diff is supposed to show the difference (both old and new
>>> values), and not just a human interpretation of what was
>>> merged/reverted. For this kind of reporting, status would be a
>>> better place (or better still, the audit, reporting tools that we
>>> are planning to develop in phase
>> IIRC prop diff output is not meant for any tools and just for human
>> eyes.
>> I feel the pretty output of 'svn:mergeinfo' prop would be more human
>> friendly than current svn diff output
>> See how bad it is
> [snip]
>> Quick question:
>> Can you from the above output can you see what got changed? (Scroll
>> down for answers)
>> Things could be even worser.
>
> Same applies even for multiple changes across 100 different files in
> the codebase. The complexity of the user changes, I beleive are not
> sufficient to change the beahvior of the 'diff' functionality.
>
You can consider this kind of 'special binary diff'. More on that
follows below.
For big set of file changes, I can always pipe to readymade
lsdiff/filterdiff, rather than writing your own awk/perl magic to parse
this mergeinfo differences.
>>> 2) The reason we have a string representation for svn:mergeinfo is
>>> so that it is hand-editable (It is not just an implementation
>>> detail, we expect the users to update svn:mergeinfo to reflect
>>> manual merges). Showing interpreted info in diff and showing the
>>> original svn:mergeinfo value in propedit will confuse the user.
>> If I understand you 'User should never be hidden the actual changes',
>> we show it when he does a 'svn propedit/pg/pl -v'.
>> If I understand you in favour of exposing the internals so that it
>> would make him to knowledgable to tweak this property to block merges
>> and such. I don't think it outweighs the crisp info one would be
>> willing to see.
>
> Nah. The main point is, It would be confusing to show a particular
> diff, while actually storing something else in the backend(especially
> when the user is allowed to hand-edit it).
>
If he hand edit his subsequent diff should show the corresponding pretty
output.
I think this can be considered as a special case of diff like 'binary
diff for PDF/gif'. i.e Each file/entity can have its own way of knowing
what got changed, not all need to be unified diff as it is currently.
Only thing is that this 'svn:mergeinfo' pretty diff is builtin unlike
--diff-cmd=some_third_party_tool.
I don't think unified diff is the useful format for 'svn:mergeinfo' prop
diffs.
I believe diff is just diff. The format is a matter of convenience, we
normally choose 'unified diff' as it is widely accepted by many tools.
As prop diffs produced by 'svn diff' are not used by external tools
atleast to my knowledge, I don't think sticking to 'unified diff'.
Only entity who can consume at least to my knowledge is human being who
is more pleased with the following output rather than the one I have
shown in earlier email.(May be someone would have scripted it to parse
it, just to keep those scripting, I don't prefer regular users to swim
the big matrix of path Vs rev list)
<snip>
Property changes on: trunk
___________________________________________________________________
svn:mergeinfo
Reverted /branches/b1:r154
Merged /branches/blah:r67:87
</snip>
Note: I never used any binary diffs in the past just heard of few for
Word doc exists.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 7 12:05:16 2006