On 08/26/2011 07:14 AM, Stefan Sperling wrote: > cmpilato, does this significantly differ from what you've done for BDB? > Will both backends have the same (or similar) behaviour if we use > this design for FSFS?
Most of what you discuss in this proposal is related to the detailed properties of the storage layer for successor-id mapping, all of which is completely irrelevant to the BDB scenario where a real database engine with well-defined semantics for this sort of thing already exist. You're using the term "cache" alot, which is definitely not the approach I took with BDB. In the BDB code, a missing successor map entry would signify a corruption of the filesystem. I can't recall for sure, but I don't believe I allowed for a way to distinguish between "This node has no successors" and "This node's successors haven't been calculated yet". (And that was likely because I didn't want to also have to deal with "This node's successors have been only partially calculated.") Of course, it's not that the data isn't calculable from the predecessor links we already store, but simply that the code assume that the table has been properly maintained since the origin of the repository, or at least backfilled in its entirety while the repository was offline. Not "cache"-like at all. Also, the BDB code does all this stuff at the transaction level, not the revision level. So, the node revision IDs of uncommitted nodes that live under txn roots can be the "value" of a successor-ID mapping. You don't have to wait until the transaction is committed before that mapping is present or valid. I'm not sure if that's useful or desireable, nor can I really tell if it differs from what you are proposing, but as neither the word "transaction" nor "txn" show up in your mail, it seemed I should call that out. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
