Re: `svn log -v' time inefficiencies

On Thu, Jun 13, 2002 at 04:24:53PM -0500, Ben Collins-Sussman wrote:
> 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?

Not really. That is some metadata, rather than a real description of what
changed. By storing a copy of "what changed" and calling it *official*, then
we better take more precaution.

Changing the author or log doesn't alter what actually happened within the
repository.

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

If we store this as a revision property, then yes: make it read-only. We
don't necessarily have to *formalize* the concept of r/o vs r/w, but I
really don't think this item should be changable.

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

Good point. Bill just pointed out what a SQL implementation would do that
would be nice and fast, and solves the deleted problem.

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