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... > Duly noted for Subversion 2.0 For now, however, we have to implement id_vtable_t. 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. > This is a first step towards making FSX IDs leaner and smarter. > > I would have assumed that an ID is constant... How can a constant value be > smart? > > It can be chosen smartly, but an id is an identifier not code. > See above. I'm trying to make the FSX IDs true IDs with no redundant data on them and to separate their internal representation from the API. -- Stefan^2. (*) Noderevs are the FSFS equivalent of what svn_fs_id_t represents. The actual FS backend may use a different underlying concept but must still provide noderev-esque semantics through the vtable.
