Martin Hauner wrote:
> Julian Foad wrote:
>> Martin Hauner wrote:
>>> i created a partial patch for diff summarize, Issue 2015.
>>
>> Thanks for the patch, but before we think about the code let's discuss
>> the requirements. This is the first I've heard of it.
>
> There was thread a few days ago:
>
> "show diffs in a gui client, how to get a list of changed files?"
OK, thanks for pointing that out, but I don't think the requirements are
discussed (functionality, output format and invocation syntax).
> My motivation behind it is to display a list of changed items in a gui
> client when I like to see the difference between branches/tags. I can
> then select an item from the list to run a "real" diff on it. So the
> summarize is something like a diff preview.
OK. For GUIs we should think mainly about the API. So, what is the best that
a GUI can do in terms of achieving this goal using the existing API? That
would be interesting to know before designing an extended API.
> A gui client would like to know if it is a file or folder because it
> doesn't make sense to run a visual diff on a folder.
Yes.
> A gui client needs the revisions so it can run diff on that file from
> the preview if i like to see a detailed diff of the changed file.
It doesn't need the revision numbers to be reported back to it, because it can
just use the same URLs and/or revision numbers that were supplied to the "diff"
command in the first place.
>>> Path, relative to the given URLs.
>>
>> That's good if LEFT and RIGHT are directories, but what if they point
>> directly to a file?
>
> For diffs between branches/tags the filename is usually the same in
> both urls. In case of a rename one could simply use the new name or
> print both: /path/newfilename (/path/oldfilename)
Those are indeed possibilities but I'm asking you to think about the various
ways in which the command could be used, decide what rules would be best, and
then propose your specification, saying something like, "The path should be
shown relative to <...> when it is <...> and otherwise it should be <...>,
because that makes the output unambiguous in all of these cases: <...>. The
only other possible cases are <...> and they don't matter because <...>."
It looks like you would like some help with this design stage (and the coding)
from others on the list, and that's fine, though I would also like to encourage
you to have a go at researching the features that we want it to be somewhat
compatible with (cvs diff, svn diff, svn status) and designing and writing up a
proposal. A good way to present it would be as a patch to the Subversion book
and/or on-line help, stating exactly what the feature does and what its output
means.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 7 20:29:28 2005