On 28.02.2011 15:22, C. Michael Pilato wrote:
> On 02/27/2011 03:39 AM, Stefan Küng wrote:
>> function to determine whether a path is part of a working copy.
>> Currently I'm misusing svn_wc_check_wc2() for this, but I'd rather have a
>> proper and fast svn_client_is_workingcopy(const char* path) function for this.
> I've often wondered about this myself. Of all the "duh" functions you'd
> think we'd offer, this one is pretty near the top. And yet folks typically
> find themselves just messing around with check_wc() or status() or ...
>> function to find the wc root path for a given path. I thought there must be
>> such a function already but I couldn't find one.
> There's this public one I added a few months ago or so:
> svn_error_t *
> svn_wc_get_wc_root(const char **wcroot_abspath,
> svn_wc_context_t *wc_ctx,
> const char *local_abspath,
> apr_pool_t *scratch_pool,
> apr_pool_t *result_pool);
> I more than happy to make an svn_client wrapper for this, and demote this to
> a private WC function, though!
Thanks! I haven't seen/found this one. I guess I have to adjust my
search strings in the future.
I can use this function, no need to provide an svn_client wrapper. But
maybe other clients could use such a wrapper...
>> A new field in the svn_client_status_t struct which has the size of the file
>> in the working copy, or -1 if not known. For most file this information
>> should be available automatically since svn_client_status has to do a stat()
>> call on the file anyway to determine its file time or at least when
>> comparing the size to its BASE. So if that information is available, I'd
>> like to reuse that info and not have to do a stat() call again later,
>> basically doubling the stat() calls and therefore hurting the performance a
> Makes sense to me.
One other thing I'd like to discuss: currently all svn functions use
streams and provide the data in callbacks to save memory. While I fully
understand that, I'd like to have at least the svn_client_proplist()
function to also provide all results in one (big) memory hunk. Because
right now, to save memory and to avoid timeout problems in the callback,
svn_client_proplist() does a db query for each and every folder and then
calls the callback function for every folder separately.
But that is painfully slow if there are hundreds of folders in a working
copy - one db query for every folder!
Since most UI clients need all the data in memory anyway, I'd like to
have a separate svn_client_proplist() API that does *one* db query and
returns all the results in one go.
There are several reasons:
* as mentioned, most UI clients will need all data in memory anyway. For
example in TSVN I just add the data in the callback to one big
list/vector/map and start using that data after the function returns.
* it is much faster (and I mean *much* faster here, from several seconds
or even minutes down to a few milliseconds or maybe two or three seconds)
* in case there's not enough RAM available: I can always tell users to
install more RAM to get it working. But there's no way to make it faster
with the current callback implementation - there just are no faster
harddrives or much faster processors.
* the chance that there's not enough RAM available is very small:
assuming a million properties, each property using 1kb will result in
1GB or RAM - most computers today have 3GB, new ones have 4GB and more.
So even in such rare situations with *huge* working copies the chance of
too less RAM is very small.
So: for UI clients please provide fast APIs that use more RAM - keep the
existing APIs that use as less memory as possible for those clients who
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2011-02-28 20:36:21 CET