On 07.01.2013 17:02, C. Michael Pilato wrote:
> 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.
The release number is actually irrelevant here. Our compatibility
guidelines are about APIs, and although they can be logically extended
to repository formats, that has never been a hard promise.
Regarding new FS concepts -- they hardly need to be
compatibility-breaking; it is, IMO, enough that they're interesting
enough that we want them, yet do not want to spend the time implementing
(and maintaining) them in two different FS backends.
One such concept that I'm sure we're all looking forward to is a
redesign of the FS API (a.k.a. FSv2). While there's no technical reason
why we couldn't convert both FSFS and BDB to this potential new API, I
have trouble finding a reasonable justification for investing time into
doing that.
> 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, ...).
FUD is avoided by proper documentation. Even today, and without
deprecating anything, it would make sense to urge users to migrate away
from BDB, merely because I don't expect anyone to invest the necessary
time to properly maintain it (other than to make tests pass).
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-01-17 12:54:48 CET