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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
