RE: svn commit: r1548823 - in/subversion/trunk/subversion/libsvn_fs_x: dag.c id.c id.h temp_serializer.ctemp_serializer.h

We revved almost the entire wc api for Subversion 1.7, with almost no breakage for the older wc apis. (8 errata if I remember correctly). I don't see why we can't do this for the fs or ra layer APIs before 2.0. The old public APIs that miss arguments won't be as fast as the newer APIs that have them but... I don't see this as an excuse to use a bad design for the fs layer until 2.0.

Bert

-----Original Message-----
From: "Stefan Fuhrmann" <stefan.fuhrmann_at_wandisco.com>
Sent: ‎8-‎12-‎2013 11:09
To: "Bert Huijben" <bert_at_qqmail.nl>
Cc: "Subversion Development" <dev_at_subversion.apache.org>
Subject: Re: svn commit: r1548823 - in/subversion/trunk/subversion/libsvn_fs_x: dag.c id.c id.h temp_serializer.ctemp_serializer.h

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...

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.
Received on 2013-12-08 13:33:00 CET