On Tue, Oct 19, 2010 at 13:12, Blair Zajac <bl...@orcaware.com> wrote: > On 10/19/2010 01:31 AM, Greg Stein wrote: >... >> Personally, I see it as a broad swath of API changes to align our >> needs with the underlying storage. Trowbridge noted that our current >> API makes it *really* difficult to implement an effective backend. I'd >> also like to see a backend that allows for parallel PUTs during the >> commit process. Hyrum sees FSv2 as some kind of super-key-value >> storage with layers on top, allowing for various types of high-scaling >> mechanisms. > > How would that API look? The API as it is is pretty clear.
Editor v2. There are a lot more constraints around modification sequences, atomicity, and whatnot. The current, unconstrained API was a major issue for Trow (e.g allowing a delete, an add, then a delete again; multiple propset changes; stuff like that). Switching it to Ev2 would also let us plug the FS more directly into how other portions of SVN will make edits to a tree. >... > 2) I would like to ensure that the new backend supports multiple > modifications to the same node. I don't know if this was designed into the > current backend, but given I expose svn_fs.h over RPC, clients can make any > one or multiple modifications to the tree, so the new backend should support > this. Why? How do you actually use this "feature"? These multiple edits are part of the problem for certain backend designs. >... > out of memory). Constructing and destroying pools in the wrong order can > cause the process to crash. This is hard to get right, so using a different > model would be very useful. We may be able to use pocore's pools and cleanups, which are more flexible. pocore will be used by serf (and possibly ra_serf), so it will typically be "around" the system during an svn build/run. Cheers, -g
