[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 23:24:53 CEST

Greg Stein <gstein@lyra.org> writes:

> 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. (!)

People can come along and change the author and datestamp on the
revision too. Is that Badness too?

> 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)

Are you proposing two kinds of revision props? Read-only vs. read-write?
I'm not sure I understand.

> 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)

It also won't detect deletions. That was the whole reason cmpilato
abandoned this approach and went back to dir_delta.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 13 23:26:54 2002

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

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