Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> Other than that, I have another idea. Right now diff handling is done
> completely in the client. There is no svn_client_diff in libsvn_client.
> Here's my thought: Make a svn_client_diff whose job is to return an
> apr_hash_t (or something), mapping filenames to the the files they should be
> diffed against.
>
> This would provide two benefits that I can see:
>
> 1) Other clients would be able to just get a mapping to do the diff, instead of
> duplicating all the recursiveness code, etc.
>
> 2) Performance-wise, this would allow you to load the entries file once per
> directory, and check all of the entries with it to determine there addedness,
> instead of re-loading the entries file for each call into
> svn_wc_get_pristine_path. This probably doesn't make too much difference on
> modern computers which will buffer the file contents anyway, but it is
> conceptually cleaner.
>
> What do you think? Are you up to a patch of this magnitude?
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);
where the client creates the hash table and the library populates it.
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?
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.
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?
Maybe a no-recursion flag as well?
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".
Don't sign me up for this one yet :-)
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:46 2006