On Tue, Jul 28, 2026 at 8:10 AM Daniel Sahlberg
<[email protected]> wrote:
>
> Den fre 24 juli 2026 kl 21:03 skrev Daniel Sahlberg
> <[email protected]>:
>>
>> Den fre 24 juli 2026 kl 18:52 skrev Nathan Hartman
>> <[email protected]>:
>>>
>>> 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?
>>
>>
>> I think this is a good plan. I would prefer to keep the announcement as
>> 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 testing
>> - but that may just be on the mailing list..? I would probably not mention
>> 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/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
>
>
> 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 Ivan
> answering Brane's concerns about modifying public API ("libsvn_fs_base
> functions 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 Čibej 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?
