On Nov 21, 2007 11:03 PM, <kmradke@rockwellcollins.com> wrote:
> "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.)
Yes, this is different, because with caching you'll be tempted to
assume there won't be a lock, though without the cache you are sure
you don't know. The former is uncertainty, the latter is certainty. In
version control (and software in a broader sense) certainty is good,
uncertainty is bad.
bye,
Erik.
---------------------------------------------------------------------
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:08:54 2007