On Nov 30, 2007 11:28 PM, David Glasser <glasser@davidglasser.net> wrote:
> On Nov 29, 2007 5:12 PM, David Glasser <glasser@davidglasser.net> wrote:
> > * ... except that the FS itself handles things like "copying a node
> > copies everything below it" and "deleting a node deletes everything
> > below it"; our current sqlite code does not handle that, making it
> > easy to corrupt the index. And implementing that for the sqlite
> > code would be tantamount to a complete Subversion-DAG-FS model
> > implemented for our index.
>
> My current plan is to spend a day or two trying to actually implement
> this instead of assuming that it's impractically hard. The good news
> is I'll stop posting proposals and strong opinions until I've done
> that :-)
After doing this yesterday, my opinion is that no, it is not
impractically hard to implement deep copies and deletes in sqlite,
especially if I also use the noderev-tagging infrastructure from my
other branch. (Also, the implementation would be easier if writes to
the database used the transaction ID instead of the revision number,
and the commit step was just either rewriting from txn to rev, or
inserting a row into a join table. Would minimize the work necessary
under the repos write-lock, too.)
*However*, I didn't actually implement it, because implementing any
sort of delete (whether "propdel" or "delete the node with
svn:mergeinfo" or "delete the parent of the node with svn:mergeinfo")
requires a way to store in the database the fact that a node that used
to have mergeinfo doesn't any more, which is not supported by the
current schema. I could invent a way to do so (eg, adding a dummy row
with rev range (-2)-(-2), like we do now for representing
svn:mergeinfo='' as (-1)-(-1)). But that of course will change how
queries work. And given that no query currently on trunk actually
needs the sqlite index, it seems backwards for me to design a schema
change without a problem to solve.
Once we have a better idea what problem we're trying to solve with
2897, and what queries are necessary, I'll see what sort of schema
makes sense, and implement this (unless our decision is that we don't
need the index at all).
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 3 21:06:24 2007