Stefan Sperling wrote:
> On Fri, Jun 18, 2010 at 01:19:18PM +0200, Stefan Küng wrote:
>> On 18.06.2010 06:46, Greg Stein wrote:
>>> The idea is: the status callback is invoked with the *limited* status
>>> information. If you want more, then from *within* that callback, make
>>> a function call back into the API to get the information you need.
>>>
>>> Look at that! No additional tree walks!
>> Would work only if I'm allowed to use API's from libsvn_wc. But
>> those are supposed to go away.
>> In the callback, I can't use svn_client_* API's because the wc is
>> locked/in-use at that time and those API's will throw an error.
>
> The old APIs behaved like that with respect to locks.
>
> But the new ones can be different. Sqlite will manage reader locks for us.
> Any function call you make results in information being looked up in the
> database, except for information that can only be found on disk.
> That's my impression, anyway (someone please correct me if I'm wrong).
>
> The idea is not to remove the functionality libsvn_wc APIs provide,
> but to stop exposing the artificial barrier between libsvn_client
> and libsvn_wc in the public API. Instead, new libsvn_client APIs
> will provide any information you may need.
This is a critical point that I failed to mention in my previous "let's stop
adding to the svn-wc API" remark. My desire is not to reveal less
information to third-parties -- it's to give them what they need from the
layer developed just for them (the *client* layer) while hiding the
implementation details of our WC. Sorry if I've added to the confusion and
concern by not laying this plan out in full and only talking about half of it.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-06-18 14:57:58 CEST