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

Re: `svn log -v' time inefficiencies

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-06-13 22:29:27 CEST

cmpilato@collab.net writes:

> To address this, Karl proposed the idea of storing the changed paths
> as a revision property. That is, as a person changes things in a txn,
> we will track the changed paths as a transaction property. Then, at
> commit time (where we already initialize the revision properties by
> copying the transaction's properties) those would become revision
> properties. Wah-lah, constant-time answers to "What changed in this
> revision?"

+1. I'm totally for this "caching" approach.

Our fs design is great and powerful, but here, before our eyes, is the
one chunk of kryptonite to our super-schema. I think caching is the
only realistic solution.

> It seems kinda Band-aid(tm)-ish to me, but only because of the
> redundancy aspect (we *can* derive that information, it just takes
> time proportional to the size of the changes made to any given
> revision). But if a Band-aid(tm) is what we need, then it's what we
> need.

I don't think this solution is bad in the traditional sense of "all
caching is bad." Why? Because this is not a real cache. Real caches
need to expire and be rewritten from time to time. But we're talking
about adding a new revision-property that is *permanent* -- it's as
permanent as the author and datestamp props; the 'changed paths' in a
revision are never going to change, because revisions are immutable.
And we have all the info at commit time already! Let's go for it.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 13 22:31:56 2002

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