Re: Outstanding Patches.

Sorry, I also wanted to say that if you wanted to be really cool,
you might be able to write a new editor and just use svn_wc_crawl_local_mods.
Otherwise svn_wc_text_modified_p might be useful.

On Tue, Oct 30, 2001 at 09:26:08AM -0500, Kevin Pilch-Bisson wrote:
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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