On Fri, Jul 24, 2026 at 11:52 AM Ivan Zhakov <[email protected]> wrote: > > On Fri, 24 Jul 2026 at 15:06, Branko Čibej <[email protected]> wrote: >> >> On 24. 7. 2026 13:57, Daniel Sahlberg wrote: >> >> Den fre 24 juli 2026 kl 13:30 skrev Branko Čibej <[email protected]>: >>> >>> On 24. 7. 2026 13:23, Branko Čibej wrote: >>> >>> On 24. 7. 2026 13:20, Ivan Zhakov wrote: >>> >>> On Sat, 18 Jul 2026 at 18:27, Nathan Hartman <[email protected]> >>> wrote: >>> > I'm glad there's a good bit of housecleaning going on around here. >>> > 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 deprecated, 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 report from >> FreeBSD that it doesn't work [2]. In the first link Yasuhito Futatsuki 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 need 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 over 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 will 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 removing BDB. >> >> >> >> What do we do with older clients that link with libsvn_fs_base when 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 change 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/libsvn_fs/fs-loader.c?revision=1936528&pathrev=1936528&view=markup#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 announcement 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 for REMOVAL with a future Subversion release line. It will not be possible 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? [1] "Berkely DB precompiled for Windows" Posted to dev@ on 26 Sept 2024 https://lists.apache.org/thread/m4o5l9rntc98y6s8wrhsn329by9bhr19 Continued here (disconnected in the archives): https://lists.apache.org/thread/99zo1wq003109p06dt1tcxyzd7cyyw32 and here: https://lists.apache.org/thread/7plrvmhk3c0jvhkq1tfwds8j4tmlgslc [2] "Removing BDB support from 1.15" Posted to dev@ on 18 Mar 2025 https://lists.apache.org/thread/kn0yw4f8p6tn2tzq4obr5r5v609g6g1m Cheers, Nathan
