Re: `svn log -v' time inefficiencies

On Thu, Jun 13, 2002 at 02:00:07PM -0700, Bill Tutt wrote:
> > cmpilato@collab.net writes:
>...
> > > 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.

Yah, a bit hacky, but it seems fine. One concern is that the rev props are
not versioned. It is theoretically possible for somebody to come along and
change the set of changed paths. (!)

To some extent, if we are going to use the derived copy in our
functionality, then we better ensure that it is correct. To that end, I
think we should do one of two things:

1) make the rev property read only
2) move it into the revision skel (not the formal schema, just the BDB
   implementation)

>...
> Just as a little side note wrt denormalization:
> In SQL datastores every additional index you add is really denormalized
> data, it's just very useful denormalized data.

Well, I'd also point out that if we had SQL, we'd just find the changed
nodes using a simple query against the TXN_ID. Of course, that finds the
*nodes*, but not the paths. (but that is a concern for another day)

CHeers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org