Re: BDB vs FSFS - OMG!

On 01/07/2013 10:07 AM, Branko Čibej wrote:
> Nevertheless the situation we have now is what it is. I see only two
> ways forward: stop supporting BDB (eventually), or invest serious effort
> into making it competitive. If we decide for the latter, it should be
> for good reasons; maintaining two back-ends is, as we know, a big
> investment.
>
> Personally I would rather spend that time doing sexy new things, such as
> the FSv2 API (getting rid of DAGs in the FS interface would be a good
> thing), better merging, replacing externals, etc. etc.

DISCLAIMER: I've always assumed that moving incrementally forward towards
the kind of storage backend that supports all the sexy new features is
simply not possible without breaking the design tenets of FSFS and/or
forcing a dump/load during migration. In my mind, if you have to dump/load
at all, that's not "incremental" enough. If that's wrong and someone has
other ideas, then I need to update my assumptions. Specifically, I guess I
don't understand the boundaries and characteristics of "FSFS format 7" vs.
"FS2", so I may not be speaking the same language as others on this thread.

---
Speaking personally, I am all for stopping the support of BDB eventually.
But unless you have some really unique work habits, any time you are really
spending on BDB today is done in backgroundable tasks -- regression test
suite runs, primarily.  That's hardly a serious time investment, and
certainly not the sort that's keeping anyone from doing sexy new work.
If we're going to force existing BDB users onto something else, they should
expect real benefit from that change.  I don't want their decision-making to
boil down to choosing amongst a) enduring a dump/load process for no
perceivable benefit, b) sticking with an old Subversion indefinitely, or c)
just bailing to another VC system.  And while the kinds of performance
numbers folks have thrown up comparing the backends are interesting, I guess
I've not yet seen a case made for FS performance being a serious bottleneck
in real-world deployment scenarios (where networks, SSL, server load, etc.
are involved).  Is it the case that 'svn update' or 'svn merge' over HTTP
from the moderately active Subversion server sitting in the corporate data
center is noticeably slower with one backend versus the other?
The Berkeley DB backend does have a finite lifespan, the end of which is
(hopefully) approaching.  But I submit that the appropriate time to pull the
plug is when we introduce a compatibility-breaking new FS concept -- the
sort that would force a dump/load from both BDB and FSFS and a major bump in
Subversion's release numbering -- which offers meaningful feature additions.
 I *think* that no one here is proposing that we actually drop BDB support
prior to such a moment in Subversion's evolution, but my concern is that the
"Deprecated" labeling will amount to FUD which scares BDB users into a
dump/load just to get onto FSFS, only to find that in the next release of
Subversion those same users are asked to dump/load again to get onto FSv2
(or FSFSv7, or TheNextBigFSThang, ...).
-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development