On 10/19/2010 02:33 PM, Greg Stein wrote:
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).
Yeah, I wouldn't want those additional constraints.
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.
It's not me, but clients of the API I expose, that allows any arbitrary
modification to a filesystem root. I like to think of the svn backend
as a versioned filesystem without any particular limitations on how it's
used, which I think is really useful. Not too many people use this, but
svn has basically the only versioned filesystem with a good API, stable
ABI, good performance.
In previous incarnations of the versioned asset management system, users
didn't have to think about what modifications they could or couldn't
make and in what order, so in the current implementation, they can do
the same thing being backed by svn, and get versioning provided by svn.
Putting this constraint on a newer backend wouldn't work for me,
unless I batch up operations from the client and apply them in one editor.
If we went with a key/value store, then it seems (without thinking about
it too much) that allowing multiple edits would be that hard, as it
could just replace an existing key/value with updated data?
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.
Cool, thanks. I'll have to check that out.
Does it provide a compatibility layer, in that you could pass pocore
allocated memory to svn functions?
Blair
