[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re: Communication of CHANGES

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-11-26 15:17:56 CET

On Nov 26, 2007 9:09 AM, Harvey, Edward <Edward.Harvey@patni.com> wrote:
> > > > Does it sound like a good idea to locally cache, in the .svn
> > > > directory, "file is out of date" information? I think so.
> >
> > > This is an interesting idea, and is obviously feasible.
> >
> > > However, could you spell out the advantage to be gained from this?
> >
> > Well, perhaps speeding up "svn status -u"?
>
> No. It's important not to change the existing behavior of anything, in
> particular svn status. It's important that "svn status" and "svn status
> -u" continue displaying exactly what they've always done.

I think he simply meant the goal is to display the same information
... faster. The original idea seemed to suggest that you could skip
checking specific items once you know there is a newer version in the
repository. IOW, if revision 5 is in the WC, you run svn status -u
and find out there is now a revision 10 of the same item, then if the
user runs the option again there is no need to check that item again,
because you already know there is a newer version.

I am skeptical that caching this information would make a significant
performance difference, and I am very much against this regardless.
We also use this API in Subclipse. much like TortoiseSVN does. While
I would love for it to run faster, I need the information to be
accurate, including the revision number. If you simply cache the
information once you know an item is out of date, then you no longer
are guaranteed to have an accurate revision number. That would be a
show-stopper for me.

Like I said, I am in favor of making something faster if it can be
done. But I also need the API to continue to be completely accurate.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 26 15:18:31 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.