Stefan Fuhrmann wrote on Sun, Dec 08, 2013 at 11:09:47 +0100: > On Sat, Dec 7, 2013 at 11:00 AM, Bert Huijben <b...@qqmail.nl> wrote: > > > > > > > > -----Original Message----- > > > From: stef...@apache.org [mailto:stef...@apache.org] > > > Sent: zaterdag 7 december 2013 10:31 > > > To: comm...@subversion.apache.org > > > Subject: svn commit: r1548823 - in > > > /subversion/trunk/subversion/libsvn_fs_x: dag.c id.c id.h > > temp_serializer.c > > > temp_serializer.h > > > > > > Author: stefan2 > > > Date: Sat Dec 7 09:30:42 2013 > > > New Revision: 1548823 > > > > > > URL: http://svn.apache.org/r1548823 > > > Log: > > > Add a pool member to the internal representation of FSX IDs and > > > thus allow the ID vtable functions to perform actual data lookups > > > in the future. The pool is the one used to allocate the ID. > > > > With WC-NG we explicitly stopped adding a pool in this kind of structures > > for very good reasons. All these pool reference makes it harder and harder > > to properly allocate results. This pattern is far too sensitive to pool > > cleanup ordering problems > > > > Using proper result and scratch pool (where the scratch pool is always the > > result pool or a descendant of the result pool or at least a pool that is > > cleaned up *before* the result pool), makes pool cleanup handling much > > easier to understand...
Incidentally, this confused me. We *depend* on scratch pools getting cleared before result pools? Normally, the lifetime of a scratch pool is explicitly undefined: it is not promised to be cleared right after the call, or before result_pool, or after result_pool; they simply promise nothing whatsoever. Do we have code that assumes otherwise? > > > > Duly noted for Subversion 2.0 > > For now, however, we have to implement id_vtable_t. Huh? id_vtable_t is not a public API. I assume the id vtable falls under the same rules as the fs_library vtable --- see fs_library_vtable_t.get_version's docstring. > It offers two > functions, the first one being an identity check is certainly o.k. > > The second one tests the following: "does this noderev(*) ID have a > common ancestor with that other noderev ID?". Unless you somehow > attach that information to the ID itself, you probably need a pool to > perform some kind of data access. But the API does not provide one.
