On 01/06/2013 05:27 AM, Branko Čibej wrote:
> As Lieven says -- FSFS has been steadily improving while BDB was
> standing still these last 6 years. IMO, if there were enough users of
> the BDB back-end to matter, we'd have been given incentive (through bad
> language on users@ ...) to do more than just keep the back-end limping
> along to make the testsuite work.
I haven't really been much considering this "deprecate BDB" question, but
there are a couple of bits of misleading information in the above that
should probably be addressed.
First, it is true that FSFS has been "steadily improving" over the past 6
years, but I think we should qualify that a bit for the sake of the casual
reader. FSFS has only improved in the past 6 years in its ability to do
what it has always done, just faster and without consuming as much disk
space. We're not talking about bold new features here. Heck, we're not
even talking about lackluster little features! I certainly don't mean to
discount the improvements that have been made, of course -- FSFS is a much
faster, much more stable backend these days (thanks largely to stefan2's work).
Secondly, and speaking as probably the person most likely to invest any
energy into the BDB backend now or in the past 6 years (notwithstanding
Julian's valiant if ill-advised foray into "obliterate"), I want to make
sure folks understand *why* I haven't (or haven't appeared to). The casual
reader might get the sense from this thread that development on the BDB
backend stopped because we were content to let "limp along". But in fact,
*my* development on the BDB backend stopped because almost every time I
wanted to add features there, I realized that those features couldn't easily
have first-class implementations in the FSFS backend while still honoring
the basic tenets of the FSFS design. (Forward history searching via
successor links comes quickly to mind, but I know I ran into this on more
than just that front.) Feature parity across the backends is beneficial for
obvious reasons, but that just means that FSFS's immutable-history design
tenet has been a hindrance to any meaningful feature-type progress for
itself *and* for any/all other backends. Of course, there are aspects of
BDB that make certain features infeasible, such as "obliterate", but from a
design limitations standpoint, FSFS has always been -- and always will be --
the bottleneck.
Finally, like stefan2 said, I'd hazard a guess that the lion's share of
remaining BDB backend users are folks whose Subversion repositories are
hosted elsewhere for them. The BDB backend (thanks to improvements to the
Berkeley DB library itself) is much more stable today than it was when we
first started this project, so it's quite possible that we don't hear noise
on users@ because a) nobody reports the problems that don't happen, or b)
they report them to their hosting service instead. That said, I am
confident that BDB usage is and has been rapidly dwindling. CollabNet still
has customers -- with ginormous repositories and gazoodles of them -- using
it, but I've lost track of precisely how widespread that is across our
customer base. Outside of CollabNet, I'd guess most of the smaller projects
migrated to FSFS long ago ... and most of the larger ones migrated to DVCS. :-)
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-01-07 03:45:22 CET