On 08.12.2013 11:09, Stefan Fuhrmann wrote:
> On Sat, Dec 7, 2013 at 11:00 AM, Bert Huijben <bert_at_qqmail.nl
> <mailto:bert_at_qqmail.nl>> wrote:
>
>
>
> > -----Original Message-----
> > From: stefan2_at_apache.org <mailto:stefan2_at_apache.org>
> [mailto:stefan2_at_apache.org <mailto:stefan2_at_apache.org>]
> > Sent: zaterdag 7 december 2013 10:31
> > To: commits_at_subversion.apache.org
> <mailto: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...
>
>
> 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.
A commendable goal, and is there an actual reason for it? Other than
saving another few bytes of storage at the expense of making the code
harder to validate, and the repo harder to debug.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-12-08 11:17:49 CET