Re: show diffs in a gui client, how to get a list of changed files?

Ben Collins-Sussman wrote:
>
> On May 27, 2005, at 3:55 AM, Martin Hauner wrote:
>
>> Max Bowsher wrote:
>>
>>> Issue 2015 - it's already filed!
>>>
>>
>> If someone outlines what has do be done in the code and where
>> i would do some work on it.
>
>
>
> Start with svn_client_diff(), and then follow the codepath for a URL-
> URL diff. My understanding is that an RA request is sent to the server
> which instructs it to compare two trees, and the result is an
> editor-drive. The particular client-side editor that is driven is
> written to drive *another* vtable known as 'diff_callbacks_t'. There
> are currently two implementations of diff_callbacks_t: one which
> prints diffs to the screen ('svn diff URL1 URL2') and one which merges
> diffs into working-files ('svn merge URL1 URL2'). The goal here, I
> believe, is to write a third implementation of diff_callbacks_t, one
> which uses our notification system to merely print status codes.

Using the notify function svn_wc_notify_func2_t would require to
extend svn_wc_notify_t. It doesn't hold all necessary information.

What would be needed?

It would at least need two new members, a second revision and the author.

The second revision because #2015 wants to see the last revision number
prior to change and the last changed revision number. svn_wc_notify_t
has only one revision. Another reason is that a gui client would need
two revisions to run a diff later.

The author because #2015 likes to see the author of the second revision.

We would also need a few more svn_wc_notify_action_t values for the
different change types so we don't need to overload existing notify actions.

The command line client would simply print the diff summarize.

A gui client would have to remember the info to display it in the gui and
to run diffs on the changed items if a user wants to see a detailed diff.

In subcommander i currently use the notify function only to print some
progress info and not to collect "real" information that will be used
elsewhere. I think the second "smells" a little bit. :) or not?

What was the orginal intention of the notify function? To print progress
information or to collect information that will/can be used somewhere else?
Or both?

I would like an api call which directly returns this information or maybe
like svn_client_status with its svn_wc_status_func2_t.

But i guess this would need more work.

-- 
Martin
Subcommander, http://subcommander.tigris.org
a x-platform Win32/Unix/Linux/MacOSX svn gui client & a text diff/merge tool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org