Re: Outstanding Patches.

On Mon, Oct 29, 2001 at 10:34:58PM +0000, Philip Martin wrote:
> Uh, yes, but I would need to know a bit more about the idea before
> deciding to try it. I assume you're thinking of something like:
>
> svn_error_t *svn_client_diff (const svn_stringbuf_t *path,
> apr_hash_t *hash,
> apr_pool_t *pool);
>
I would say something more along the lines of:

svn_error_t *svn_client_diff (apr_hash_t **pfiles,
                              const svn_string_t *target,
                              svn_boolean_t recurse,
                              svn_revnum_t from_revision,
                              svn_revnum_t to_revision,
                              apr_pool_t *pool);
>
> where the client creates the hash table and the library populates it.

I would have the library create it in the pool given by the client,
but it is up to you.

> Perhaps it should have an extra svn_boolean_t argument to indicate
> whether to return all files or to ignore those known to be unchanged?

I don't see the usefullness of returning files known to be unchanged.

>
> Listing a hierarchy of files in "hash order" will mean that files in
> any one directory will not be listed sequentially, is this a problem?
> It would be different to CVS and ClearCase.

Good point, it might be better to use an apr_array_header_t and keep
them in order (since we will likely just be iterating over them anyway,
we don't need the fast access). There was also something posted to apr
recently about a hash that guarantee's that an iterator will traverse in
the same order that elements were inserted, but I don't know whether it
ever got added or not.
>
> The client might want a list of directories as well as files, so
> perhaps a second hash for those? Or should the directory list be a
> separate function? Hmm, diff doesn't appear to show directories, I
> assume one day it will?

It will, but that will most likely be done with an xml-style patch. Take
a look at the output of svn commit --xml-file blah.xml for a sample.
but imagine the txdeltas being inline unidiffs instead of post-fix svndiff
data.

>
> Maybe a no-recursion flag as well?

Definitely.

> When using the '-r N' option to diff, data returned by RA will need to
> be put into temporary files. Where would they go in this scheme? Some
> part of the code will need to create temporary files. Is the library
> or the client responsible for deleting them? How does the code keep
> track of them? I suppose all the temporary files could go in a single
> temp directory which is later emptied, a sort of "file pool".

That isn't supported yet, and my suggestion would be to get the diff against
local version working well first, (but passing target revision numbers
for later expansion).

> Don't sign me up for this one yet :-)
>
How about now? :)

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~