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
>> 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
Received on 2010-10-19 23:33:58 CEST