On 08.12.2013 11:52, Stefan Fuhrmann wrote:
>
>
>
> On Sun, Dec 8, 2013 at 11:27 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name
> <mailto:d.s_at_daniel.shahaf.name>> wrote:
>
> Stefan Fuhrmann wrote on Sun, Dec 08, 2013 at 11:09:47 +0100:> >
> >
> > 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.
>
>
> True, but the following API simply don't provide any more information:
>
> svn_fs_check_related(const svn_fs_id_t *a, const svn_fs_id_t *b)
> svn_fs_compare_ids(const svn_fs_id_t *a, const svn_fs_id_t *b)
>
> So, our private vtable depends on the data provided by public API.
> Adding the pool member to the internal struct is exactly the way to
> decouple the implementation from the existing public interface.
There's nothing wrong with revising the public API to require a scratch
pool. Sure, the deprecated, pool-less version will be less efficient.
But I've yet to hear why "lean and smart", i.e., unstructured IDs are so
much better. than what we have currently. After all, their structure
matches the semantics of our repository model, regardless of implementation.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-12-08 16:54:25 CET