RE: Re: Communication of LOCKS and CHANGES

>> Apparently 2 GUIs (both TortoiseSVN and Ankh) have felt it was useful
>> to provide "cached" lock information to their users. Since there
isn't a
>> common
>> API to store this information, any user who uses both tools may see
>> conflicting
>> information. This is bad.

>Right. But where it went wrong is that they started caching
>information which we have thought long and hard about caching but
>decided against. It wasn't something we left out after tossing a
>coin...

>> Adding a common caching mechanism is one
>> was to solve this issue. (Probably not the only way, and possibly
not the
>> best way.)

>But introduce new ones. We don't want part in (a) caching [because we
>don't believe in it as a sound solution to the problem] (b) resolving
>the problems resorting from caching.

I think we might have a semantics issue here. You seem to be using the
term cache to mean something other then what we do.

Subversion saves admin data about the files and directories that are in
the working copy. That data represents the values for the revisions
that were requested *at the time that they were last requested*.

That Admin data is what we are calling a cache. Its what Tortoise, Ankh
and other clients use when they present the GUI views. Based on our
view of caching, you do believe in it... because that's what you
implemented.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 22:16:30 2007