David Glasser wrote:
> * I have a completely working implementation for FSFS that keeps
> enough metadata in the DAG itself to answer that question
> efficiently. So we really don't need to use sqlite for that.
> It would probably require a db format bump, but that's not too big a
> deal (and wouldn't really need a dump/load; I can give more details
> if you want). Hopefully the BDB implementation wouldn't be hard
> either.
I will gladly assist with the BDB implementation if you need me to.
> * We disable "log -g" for 1.5. "log -g" was originally proposed as a
> 1.6 command; it only switched to 1.5 because Hyrum finished his
> implementation. (And there are a lot of good things about log -g; I
> certainly have respect for Hyrum's work, and expect that 1.6 could
> contain a fixed version of it.) This would allow us to ignore the
> "log -g" bugs for now and focus on bugs more central to merge
> tracking as opposed to just this one auditing feature
>
> * Because we no longer need it, we remove the sqlite mergeinfo index
> from 1.5. This reduces a huge amount of code complexity in the FS
> backends, and lets us not worry about fixing the bugs in keeping the
> indices up to date. Because we don't need it, we don't use my
> extra-metadata-in-DAG thing either.
Are you saying that you think adding the extra-metadata-in-DAG is a bad idea
right now? And am I reading correctly that if we *had* that today, we could
still release 1.5 without the sqlite mergeinfo index and with 'svn log -g'
support?
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Nov 30 04:04:27 2007