Hey all... figured that I would drop my current thoughts on wc-ng...
A few days ago, I got my workqueue stuff checked in, and then I've
added a couple operations to it. In that process, I've discovered that
the bulk of the work done by those is manipulating the pristine text
bases, and the property files. Yet, in our future, complete wc-ng
environment *none* of those operations would be necessary. In other
words, the vast majority of that work is directly caused by *pre*
I think it is going to be inefficient to continue on the path of "move
loggy to workqueue" in a brute force fashion, like I've just done. If
we could get to the new pristine system, and get the props stored into
the database, then these workqueue operations would be *much* simpler.
So I believe that my next step is to get the pristine files and the
props advanced to our next generation. There are a lot of assumptions
in our codebase that need to be solved to continue forward. Much of
the code is not ready or flexible enough for the wc-ng approach. There
are a lot of bits that assume various files, and they manipulate those
files, and shove them around, and do whatever. Lots of trouble.
From my investigation this past evening, we have a giant knot. We have
pristines, properties, per-dir, loggy, and workqueue all tightening
into a ball. The simple edge cases are getting fixed, and leaving us
with an ever-nastier ball of twine to unravel. This email is kind of
an update to say that I'll be teasing at that knot.. trying to find
the right piece to unwind it all. It's a bit hidden now.
Two action items:
1) continue the shift to wc-ng by removing adm_access and entry_t
2) find me on IRC; I'd like to bounce un-knotting ideas around
Obviously, any questions, comments, ideas, suggestions, and patches
would be very helpful. Email discussion is great, and IRC is faster;
Received on 2009-09-21 09:40:16 CEST