Marcus Rueckert wrote:
> On 2004-11-18 11:59:07 -0500, Michael Sweet wrote:
>
>>Couldn't you just cache and update (as needed) the last blame results
>>in the WC, i.e. add a "blame-base" subdirectory in the .svn directory
>>which stores the last results of "svn blame" along with the then-current
>>revision.
>
>
> i thought about something similar for log caching but i would use
> ~/.subversion/cache/<reposuuid>/log/<file for each log message>
>
> the log messages are maybe stored as xml or in the usual format from
> svn. so a client would cache the log messages when running svn up and
> svn log could check the cache before asking the repos. similar stuff
> could be done for svn blame.
My thought was that the WC code doesn't need to be changed to
implement blame/log caching right now - the blame/log commands
could be worked on to come up with the "right" implementation
separate from any WC changes, and then when the WC code is redone
for 2.0 those caching optimizations could be designed into the
new 2.0 WC code.
In short, let's experiment in a client app using the current WC,
find out what works, and *then* change the WC.
> for the log caching it would be usefull to enable it per working copy. i
> dont think it has to be enabled by default. but where should the
> information about the flag be stored? in the WC?
~/.subversion/config is the logical place, I think, since the
caching/non-caching behavior is likely to be a user-specific
preference, not a repo-specific one, i.e. some people do a lot
of off-line work and/or use the log/blame command more than
others, and they do it consistently for all of the projects
they participate in...
Of course, I could be totally off-base here, but most people I
know are pretty predictable that way... :)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 18 21:54:59 2004