Philip Martin wrote:
> 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.
You are right.
> >
> > - if it is a folder or a file
>
> A modified item has two types, before and after, they might not be the
> same.
Ok, we can add another type so have a before and after type.
> > (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.
Wouldn't i need the info file/dir in your case too? My point was that
you would have to know if it is file or folder to decide how to run a
diff on that item.
> > - 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.
Yes, libsvn_client. Change that to: there is currently no >easy< way.. :)
I don't know how much effort is necessary to create an svn_delta_editor_t.
Is it an easy task?
> > 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.
I'm assuming that this is already handled by the (diff) code that calls
the svn_wc_diff_callbacks2_t functions. So that i could simply copy the
parameters from the callbacks into the preview structure.
> > /** 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.
Yes, like that. Another possibilty would be to add new items on the fly
into the gui while the preview is running to get earlier feedback.
> But I suppose it could give the user a yes/no choice as each callback
> runs?
Yes, that's another posibility. I prefer to provide a list from which
the user can choose. I can quickly go the file i like to see and won't
have to click through all files to get to the wanted file.
> 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.
Ah, i do understand now why Julian was talking about client/server
interaction. :)
> 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?
Yes i could retrieve them later. I included it because the info is
availabe from the svn_wc_diff_callbacks2_t functions. Another reason
is simply that i would need less code in the gui tool. :)
> 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).
+1, if it counts..
--
Martin
Subcommander, http://subcommander.tigris.org
a crossplatform Win32/Unix/MacOSX svn gui client & diff/merge tool.
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 9 10:06:48 2005