Stefan Fuhrmann wrote on Sun, Dec 08, 2013 at 11:09:47 +0100:
> On Sat, Dec 7, 2013 at 11:00 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> > > Sent: zaterdag 7 december 2013 10:31
> > > To: commits_at_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.
Received on 2013-12-08 11:28:08 CET