Re: State of BDB FS backend

On Tue, Jul 28, 2026 at 9:58=E2=80=AFAM Nathan Hartman <hartman.nathan@gmai=
l.com> wrote:
>
> On Tue, Jul 28, 2026 at 8:10=E2=80=AFAM Daniel Sahlberg
> <[email protected]> wrote:
> >
> > Den fre 24 juli 2026 kl 21:03 skrev Daniel Sahlberg <daniel.l.sahlberg@=
gmail.com>:
> >>
> >> Den fre 24 juli 2026 kl 18:52 skrev Nathan Hartman <hartman.nathan@gma=
il.com>:
> >>>
> >>> On Fri, Jul 24, 2026 at 11:52=E2=80=AFAM Ivan Zhakov <[email protected]=
> wrote:
> >>> >
> >>> > On Fri, 24 Jul 2026 at 15:06, Branko =C4=8Cibej <[email protected]> =
wrote:
> >>> >>
> >>> >> On 24. 7. 2026 13:57, Daniel Sahlberg wrote:
> >>> >>
> >>> >> Den fre 24 juli 2026 kl 13:30 skrev Branko =C4=8Cibej <brane@apach=
e.org>:
> >>> >>>
> >>> >>> On 24. 7. 2026 13:23, Branko =C4=8Cibej wrote:
> >>> >>>
> >>> >>> On 24. 7. 2026 13:20, Ivan Zhakov wrote:
> >>> >>>
> >>> >>> On Sat, 18 Jul 2026 at 18:27, Nathan Hartman <hartman.nathan@gmai=
l.com> wrote:
> >>> >>> > I'm glad there's a good bit of housecleaning going on around he=
re.
> >>> >>> > We've accumulated so much cruft over the years, it makes my
> >>> >>> > head spin. +1 to axe the ctypes bindings.
> >>> >>>
> >>> >>> Speaking of cleanups, another candidate comes to mind: the BDB FS=
 backend. I think now would be an appropriate time to remove it:
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> We can't remove it before 2.0. It doesn't matter that it's deprec=
ated, it's part of the published 1.0 feature set.
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Just to be clear: the existence of the BDB back-end is equivalent=
 to a public API. We have many deprecated public APIs that we can't remove =
for the same reason.
> >>> >>>
> >>> >>> -- Brane
> >>> >>
> >>> >>
> >>> > [...]
> >>> >>
> >>> >> This was discussed previously [1] and we even received a bug repor=
t from FreeBSD that it doesn't work [2]. In the first link Yasuhito Futatsu=
ki was of the opposite opinion: the FS type is not a public API. I tend to =
side with him but I could be convinced otherwise.
> >>> >>
> >>> >> As Yasuhito point out, SVN_FS_TYPE_BDB is a public API which we ne=
ed to keep. I didn't study details but I assume the code in libsvn_fs_base =
only implement a filesystem API reachable via the fs loader (this is way ov=
er my paygrade so please educate me if I misunderstand something!). In that=
 case, we won't break anyone's code so anything that compiles under 1.14 wi=
ll still compile under 1.16, but it it would not be able to load the BDB FS=
 backend (just as if you didn't compile it in the first place).
> >>> >>
> >>> >> Of course - we would force anyone using a BDB backend to do a dump=
-and-reload cycle as part of their upgrade.
> >>> >>
> >>> >> Provided my understanding above is correct, I'm in favour of remov=
ing BDB.
> >>> >>
> >>> >>
> >>> >>
> >>> >> What do we do with older clients that link with libsvn_fs_base whe=
n a library upgrade makes that go away? At the very least we'd have to keep=
 a stub that implements all exported functions, or we break the ABI.
> >>> >>
> >>> >
> >>> > As far as I see libsvn_fs_base functions are not publicly exported.=
 We have some BDB FS specific functions [1] in libsvn_fs, but they already =
stub to newer API and I agree we should keep them.
> >>> >
> >>> >>
> >>> >> In other words, even if we decide that removing BDB support isn't =
an API violation, we can't do this in 1.15 because it's not a trivial chang=
e of removing a directory and a couple lines from build.conf.
> >>> >>
> >>> > I agree and I don't think we should be doing anything about BDB in =
1.15 at this point (except for release notes). The proposed plan was about =
removing it in trunk / 1.16.
> >>> >
> >>> > [1]: https://svn.apache.org/viewvc/subversion/trunk/subversion/libs=
vn_fs/fs-loader.c?revision=3D1936528&pathrev=3D1936528&view=3Dmarkup#l786
> >>> >
> >>> > --
> >>> > Ivan Zhakov
> >>>
> >>>
> >>> This was discussed several times before, such as [1], [2].
> >>>
> >>> Arguments in favor of removing BDB:
> >>>
> >>> (1) It has been deprecated for a long time.
> >>>
> >>> (2) AFAICT most devs are no longer testing BDB so maybe it works, or
> >>> maybe it bitrotted.
> >>>
> >>> (3) Last I checked, some kind of registration was needed to get the
> >>> official sources?
> >>>
> >>> (4) It might not have many (or any) users anymore.
> >>>
> >>> Arguments against removing it:
> >>>
> >>> (1) API guarantees...
> >>>
> >>> (2) Questions about what's involved in actually ripping it out.
> >>>
> >>> (3) Users with BDB-backed repos would need to dump and load them
> >>> BEFORE we remove it...
> >>>
> >>> ...and that means we need to give very clear, advance notice.
> >>>
> >>> So this is my suggestion: For now, let's start by making the
> >>> announcement together with the 1.15.0 release. I suggest to put the
> >>> announcement in the 1.15 release notes as well as creating a separate
> >>> news item for it. In the announcement, we won't commit to removing it
> >>> by a specific date or release. We'll just convey that its removal is
> >>> being planned and may be imminent.
> >>>
> >>> After the announcement is made, Let's take as long as we need to
> >>> figure out the issues of API guarantees, how/what to remove, etc.
> >>> There's no rush to do the actual removal, but I think the announcemen=
t
> >>> needs to give users as much time as possible.
> >>>
> >>> Proposed initial draft of announcement:
> >>>
> >>> [[[
> >>>
> >>> IMPORTANT NOTICE: Subversion's Berkeley DB repository backend (BDB)
> >>> has been deprecated since Subversion 1.8 (13 years) and is planned fo=
r
> >>> REMOVAL with a future Subversion release line. It will not be possibl=
e
> >>> to access BDB-backed Subversion repositories after upgrading to a
> >>> Subversion release that no longer supports it. The Subversion 1.15.x
> >>> release line may be the last minor release line to support the BDB
> >>> backend.
> >>>
> >>> Users who have BDB-backed Subversion repositories should upgrade them
> >>> to the newer FSFS backend as soon as possible to avoid disruption.
> >>> FSFS has been the default since Subversion 1.2 (21 years). This
> >>> requires to "dump" the repository using a Subversion release that
> >>> supports BDB and then to "load" the repository using any recent
> >>> Subversion release. For details, please see the FAQ entry "How do I
> >>> convert my repository from using BDB to FSFS or from FSFS to BDB?":
> >>> https://subversion.apache.org/faq.html#bdb-fsfs-convert
> >>>
> >>> ]]]
> >>>
> >>> Commenting on my own initial draft:
> >>>
> >>> Instead of sending them to the FAQ, maybe we'd want to write clear
> >>> backup/dump/load instructions directly in the announcement?
> >>>
> >>> Do we want to point out that the BDB backend might not be as well
> >>> tested as FSFS these days?
> >>>
> >>> WDYT?
> >>
> >>
> >> I think this is a good plan. I would prefer to keep the announcement a=
s short as possible and link to the FAQ, improving that if needed.
> >>
> >> I seem to remember that we at one point has talked about the lack of t=
esting - but that may just be on the mailing list..? I would probably not m=
ention it in the announcement - either something is supported or it is NOT =
supported.
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >>>
> >>>
> >>> [1] "Berkely DB precompiled for Windows"
> >>>     Posted to dev@ on 26 Sept 2024
> >>>       https://lists.apache.org/thread/m4o5l9rntc98y6s8wrhsn329by9bhr1=
9
> >>>     Continued here (disconnected in the archives):
> >>>       https://lists.apache.org/thread/99zo1wq003109p06dt1tcxyzd7cyyw3=
2
> >>>     and here:
> >>>       https://lists.apache.org/thread/7plrvmhk3c0jvhkq1tfwds8j4tmlgsl=
c
> >>>
> >>> [2] "Removing BDB support from 1.15"
> >>>     Posted to dev@ on 18 Mar 2025
> >>>       https://lists.apache.org/thread/kn0yw4f8p6tn2tzq4obr5r5v609g6g1=
m
> >>>
> >>> Cheers,
> >>> Nathan
> >
> >
> > It has been over four days and no further discussion on this thread so =
I'd like to try making a summary. The last technical comment was made by Iv=
an answering Brane's concerns about modifying public API ("libsvn_fs_base f=
unctions are not publicly exported. We have some BDB FS specific functions =
in libsvn_fs, but they already stub to newer API and I agree we should keep=
 them").
> >
> > @Branko =C4=8Cibej Does this satisfy your concerns?
> >
> > Anyone else?
> >
> > Cheers,
> > Daniel
> >
> >
> >
>
> Currently 'svnadmin help create' has this to say about the --fs-type arg:
>
>   --fs-type ARG            : type of repository:
>                              'fsfs' (default), 'bdb' or 'fsx'
>                              CAUTION: FSX is for EXPERIMENTAL use only!
>
> Perhaps there should also be a "WARNING: BDB will be removed in an
> upcoming release?" or something to that effect?


I have drafted a notice of BDB's impending removal in the 1.15 release note=
s
in r1936672.

Feedback welcome; in particular, if there are any developer considerations
that need to be mentioned there, such as applications that link to
libsvn_fs_base or use certain public APIs that will need to take action,
please point those out.

Thanks,
Nathan