"Erik Huelsmann" <ehuels@gmail.com> wrote on 11/21/2007 03:25:38 PM:
> On Nov 21, 2007 10:14 PM, Moore, Tom <Tom.Moore@aig.com> wrote:
> > >> 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.
>
> All of the data cached isn't transient... That is a *HUGE* difference.
> We don't think caching transient data is the solution to the problem
> you're trying to solve.
Well, I would argue that the file contents themselves could be considered
transient, since they can (and will) change without explicit notification.
(Yes, the repo revision will increase, but so does time itself, which is
another piece of info about the working copy state.)
Are unversioned properties cached in the admin area? (I honestly do not
know)
They are the most similar thing I could think of to locks...
Anything that can be done to prevent contacting the server is a win in
my opinion.
We are all making assumptions in what the user is thinking at the
time they decide to modify a file. The current implementation is
assuming the user is aware that real-time lock information is not
available in the working copy data.
This is possibly incorrect, since they may be assuming no information
means
the file isn't locked. (This is no different if the data is cached or
not.)
Assumptions are just bad.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 23:04:13 2007