Martin Hauner <martin.hauner@gmx.net> writes:
> This is about getting a usable gui interface for diffs between urls
> like tags or branches.
Perhaps I don't quite understand what you are proposing, but I suspect
that if you create this new interface there will be users that want it
to accept wc paths as well as URLs.
> A usable interface for a gui client is to present a list of modified
> items between the diff targets as a diff preview. The user can then
> decide on which item she likes to see a detailed diff in a visual diff
> tool by running a normal diff on the items of the list.
>
> The diff preview should take the same (diff) parameters as diff and
> diff_peg and should provide the following information:
>
> for each modified item:
>
> - if it was added, modified or deleted
>
> - if it has property changes
>
> - the items path relative to its diff target (as in a normal diff)
> Possibly two paths: its old and new name if the item was moved or
> copied.
Move detection might be tricky.
>
> - if it is a folder or a file
A modified item has two types, before and after, they might not be the
same.
> (it doesn't make sense to run a visual
> diff on a folder)
Why not? One could generate two text files containing the directory
contents, one item per line, sort them and then run a textual diff to
show items added and deleted. Property changes make as much sense on
directories as they do on files.
> - its mime type (the gui could decide based on the mime type which
> diff tool to run, ie. binary or text)
>
>
> There is currently no way to get a diff preview from the svn api.
Do you mean the libsvn_client API? The libsvn_ra API allows it if you
write an appropriate svn_delta_editor_t, although it does have to
handle text-deltas.
> The
> only known solution is to parse the text output from diff for the
> Index: or ---/+++ lines.
>
> I think the svn api is missing a clean way to provide this information.
>
>
> In the thread "show diffs in a gui client, how to get a list of changed
> files?" people like to see this info or a similar info in the shell too.
>
> To the cli users: Is it the same info like above or is it more like
> issue #2015, diff summarize?
>
>
> Implementation for gui:
>
> To get the information for the gui use case i would like to see two
> new api calls svn_client_diff_preview/svn_client_diff_preview_peg or
> new parameters to svn_client_diff2/svn_client_diff_peg2 to return the
> preview info. I think it would be nice to provide this info through
> an svn_client_status like callback and structure.
>
> typedef void (*svn_diff_preview_func_t) (void *preview_baton,
> svn_diff_preview_t *diff);
>
>
> typedef struct svn_diff_preview_t
> {
> /** file or dir */
> svn_node_kind_t node_kind;
>
> /** item paths, relative to the old diff target and new diff target */
> const char* path_old;
> const char* path_new;
>
> /** the mime types of old and new */
> const char *mimetype_old,
> const char *mimetype_new,
>
> /** change kind: unchanged, added, modified or deleted */
> svn_preview_kind_t preview_kind;
What about move/copy? Does the client deduce it from the paths? I'm
really not sure how move/copy will work.
>
> /** properties changed? */
> svn_boolean_t props_changed;
>
> } svn_diff_preview_t;
>
>
> This information is easily provided through a new implementation
> of svn_wc_diff_callbacks2_t. The callbacks already provide all the
> needed information and could simply create an svn_diff_preview_t
> and pass it to svn_diff_preview_func_t.
I'm not sure how you see this interface being used. How is the GUI
going to use your new svn_diff_preview_func_t callback? I guess it's
going to run svn_client_diff_preview to completion, and then allow the
user to choose modified items based on stored svn_diff_preview_t info.
But I suppose it could give the user a yes/no choice as each callback
runs?
One of the problems of the "easy" implementation is that there is no
libsvn_ra interface that will do the work without getting the
text-deltas. That means that svn_client_diff_preview is going to
receive (and discard?) all the text-deltas. Then when a modified item
is chosen the client is going to need to need that text-delta again,
or it's going to need to retrieve both full-texts.
svn_client_diff_preview is also going to receieve all the property
changes, although since you propose to include property information in
svn_diff_preview_t this appears to be necessary. However you don't
appear to be storing the changes (and I'm not sure storing them would
be feasible) so once again, when the modified item is chosen the
client is going to have to retrieve the properties again.
Also I'm not sure whether svn_diff_preview_t really needs to provide
the mime-types. The client will need to retrieve the properties once
the modified item has been chosen, so the mime-types will be
available, why does it need to have them in advance?
In the short term I suppose a new svn_wc_diff_callbacks2_t will
do, in the long term we might need a new RA function that tells us
which things have changed without sending the details of the changes,
i.e. no text-deltas (and maybe no property changes either).
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 9 03:46:00 2005