proposing some other enhancements and a few questions

[Ich Selbst <ic...@gmx.ch>]

Hi,

I just want to throw in some ideas for enhancements:

- when doing network access it would be nice to get
  information like transferspeed, total amount of data
  sent/received and how much data still needs to be
  transferred. This would be usefull not only with slow
  internet connections but also when transferring big files.
  Maybe another callback routine providing this kind of
  information for the clients?
  Right now if I check out or commit a very big file
  I can't tell if the operation is still running or if
  the operation crashed or just hangs or maybe the
  connection works fast.
  I think such functionality would require digging deep
  into the networking functions, right?

- the function getstatus seems to be very slow if
  doing this for folders with many subfolders even if 
  one only requests the status nonrecursive. Is it really
  vital to first lock the dirs before gathering the status?
  I don't know much about the internals though if it IS vital
  then just ignore me :)
  I'm complaining about this cause my shell integration
  makes the explorer react sluggy just to show icon overlays
  according to the subversion status...
  Or maybe I'm using the wrong function? I'm using svn_wc_status - 
  is there a faster way to get only the text status of a single file?

Some questions:
- how can I set a proxy on a client basis? I know that those
  settings are stored in the registry (on windows) under
  tigris.org/subversion but is it possible to set the "root" of 
  the registry during compile time to something different like
  HKLM/Software/MySubversionClient/...? That way each
  client could use different settings (or one client could manage 
  different settings itself).

- like the settings of the proxy is there a possibility to
  set the path to the diffutils? I'd like to put them in the
  client program folder (and use those which don't need cygwin).

Steve

Re: proposing some other enhancements and a few questions

[Ich Selbst <ic...@gmx.ch>]

> > - the function getstatus seems to be very slow if
> 
> getstatus?  Is this svn_wc_status to which you later refer?

yes.

> 
> >   doing this for folders with many subfolders even if 
> >   one only requests the status nonrecursive. Is it really
> >   vital to first lock the dirs before gathering the status?
> 
> Are you creating a recursive or non-recursive access baton?  Are you
> creating a read-only or a read-write access baton?
good hint - checking right now...
silly me - I used a recursive access baton! Thank god that
being stupid doesn't hurt :)

Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: proposing some other enhancements and a few questions

[Philip Martin <ph...@codematters.co.uk>]

"Ich Selbst" <ic...@gmx.ch> writes:

> - the function getstatus seems to be very slow if

getstatus?  Is this svn_wc_status to which you later refer?

>   doing this for folders with many subfolders even if 
>   one only requests the status nonrecursive. Is it really
>   vital to first lock the dirs before gathering the status?

Are you creating a recursive or non-recursive access baton?  Are you
creating a read-only or a read-write access baton?

A non-recursive, read-only lock should not be expensive, as far as I
know, although there is an apr_stat() call.  Recursive locks are more
expensive than non-recursive locks since they involve reading and
parsing the entries files.  Write locks are more expensive than
read-only locks since they write to the physical filesystem.

>   I don't know much about the internals though if it IS vital
>   then just ignore me :)
>   I'm complaining about this cause my shell integration
>   makes the explorer react sluggy just to show icon overlays
>   according to the subversion status...
>   Or maybe I'm using the wrong function? I'm using svn_wc_status - 
>   is there a faster way to get only the text status of a single file?

That depends on what you mean by "text status".

However you do it, single-shot operations need to parse the entries
file.  This is inevitably far more expensive than a single stat()
call.  If the file's timestamp is later than the one recorded in the
entries file then svn_wc_status does a byte-for-byte comparison of the
file and it's text-base to determine if it is modified.  If all you
want is an svn_wc_entry_t* then svn_wc_entry() is probably faster.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org