On Apr 26, 2012 12:55 PM, "Daniel Shahaf" <danielsh_at_elego.de> wrote:
>
> danielsh_at_apache.org wrote on Thu, Apr 26, 2012 at 16:30:45 -0000:
> > Author: danielsh
> > Date: Thu Apr 26 16:30:44 2012
> > New Revision: 1330932
> >
> > URL: http://svn.apache.org/viewvc?rev=1330932&view=rev
> > Log:
> > Follow-up to r1330906: fix/work-around trail reentrancy assertions in
BDB.
> >
> > (Why is the uuid stored in svn_fs_t->fsap_data rather than in svn_fs_t
proper?)
> >
> > * subversion/libsvn_fs/fs-loader.c
> > (cache_uuid): New function.
> > (svn_fs_open, svn_fs_create): Call it after everything else.
> > (svn_fs_open_berkeley, svn_fs_create_berkeley): Ditto.
>
> The purpose of this is to cause UUID to be cached in BDB's
> svn_fs_t->fsap_data so that the new-in-r1330906 calls to
> fs->vtable->get_uuid() wouldn't provoke the "run a transaction"
> codepath of svn_fs_base__get_uuid().
>
> That seems a bit fragile; I'm not sure whether a better fix should be
> found (get the UUID within the existing trail) or whether this should be
> documented and svn_fs_base__get_uuid() annotated to point out that the
> "run a trail" codepath now only runs once at the time of opening the
> svn_fs_t.
>
> Thoughts?
Put the uuid into svn_fs_t and fill it at creation time using the vtable.
Change svn_fs_get_uuid to return that, rather than using the vtable.
If there is a way to change it, then do the right magic to reset the value
in svn_fs_t, as appropriate.
Cheers,
-g
Received on 2012-04-26 19:30:28 CEST