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