Re: svn commit: r1036078 - in /subversion/trunk/subversion: include/svn_fs.h libsvn_fs/fs-loader.c libsvn_fs/fs-loader.h libsvn_fs_base/fs.c libsvn_fs_base/tree.c libsvn_fs_base/tree.h libsvn_fs_fs/fs.c libsvn_fs_fs/tree.c libsvn_fs_fs/tree.h

On 11/17/2010 02:26 PM, Blair Zajac wrote:
> On 11/17/2010 07:26 AM, cmpilato_at_apache.org wrote:
>> Author: cmpilato
>> Date: Wed Nov 17 15:26:33 2010
>> New Revision: 1036078
>>
>> URL: http://svn.apache.org/viewvc?rev=1036078&view=rev
>> Log:
>> Fix a library dependency issue which was causing build failures. (As a
>> general rule, code inside the FS providers shouldn't call back into
>> the public FS API.) Sadly, the constraints of our system (namely the
>> BDB side of things) necessitate code duplication rather than sharing.
>
> Could we do something like having the .c files #include other .c files
> that share common code?

If we do so, we have use only functions common to both backends. Such
functions only exist in the libsvn_fs library itself. But using libsvn_fs_
functions means the BDB code is re-entering the FS API, which is dangerous
in many cases (due to the problem of nested Berkeley DB transactions, which
cause hangs).

The only really enjoyable solution is for the business logic of our backends
to be combined and made to use a generic storage logic API which differs
from backend to backend. Something to strongly consider / require for FS-NG.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand