On Tue, Oct 19, 2010 at 13:12, Blair Zajac <blair_at_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
> 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
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.
Received on 2010-10-19 23:33:58 CEST