[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[RFC] Deprecate Berkelety DB filesystem backend

From: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 05 Jan 2013 02:34:39 +0100

For the following reasons

  * FSFS has been the default filesystem backend for almost 7 years,
    since 1.2.

  * Looking at commit history, I've not seen a single (functional or
    performance) improvement, beyond a few bug fixes, in the BDB backend
    in at least two years. The last significant change that I'm aware of
    was released in 1.4 (support for BDB 4.4. and DB_REGISTER) back in
    2006. In effect, BDB is in "barely maintained" mode whereas
    interesting things are happening to FSFS all the time.

  * I cannot remember seeing a BDB-related bug report in a month of
    Sundays (meaning that it's either rock-solid, or not used).

  * The BDB backend is an order of magnitude slower on trunk than FSFS
      o timing parallel "make check" on my 4x4-core i7+ssd mac:
          + FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
          + BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s

I propose that we:

  * Declare the BDB backend deprecated in 1.8, adding appropriate
    warnings when it's used or manipulated (to svnadmin?)

  * Stop supporting it (including bug fixes) in 1.9

  * Completely remove the BDB-related code in 1.10 (I'm making an
    assumption that we'll have the FSv2 API and releated refactoring of
    FSFS by then, and at least a draft experimental FSv2 implementation).

I realize I'm raising this question at a time when we should be focusing
on branching 1.8. On the other hand, this release may be a good
opportunity to deprecate the Berkeley DB filesystem.

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-01-05 02:35:18 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.