Re: State of BDB FS backend

Ivan Zhakov <[email protected]> Fri, 24 Jul 2026 18:52:37 +0300
Newsgroups gmane.comp.version-control.subversion.devel
Message-ID <CAPZho0-1=zEZOHn3S-Kn2oWndwANrB5Z4-8w55=mwjyFAkCJiw@mail.gmail.com>
--00000000000051619c06575d5d41
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 <[email protected]>:
>
>> 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 <[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 wa=
s
> 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 BD=
B
> 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 a=
t
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-load=
er.c?revision=3D1936528&pathrev=3D1936528&view=3Dmarkup#l786

--=20
Ivan Zhakov

--00000000000051619c06575d5d41
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">On Fri, 24 Jul 2026 at 1=
5:06, Branko =C4=8Cibej &lt;<a href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a>&gt; wrote:</div><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <div>On 24. 7. 2026 13:57, Daniel Sahlberg
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">
        <div dir=3D"ltr"><span style=3D"background-color:transparent">Den
            fre 24 juli 2026 kl 13:30 skrev Branko =C4=8Cibej &lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;:</s=
pan></div>
        <div class=3D"gmail_quote">
          <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>
              <div>On 24. 7. 2026 13:23, Branko =C4=8Cibej wrote:<br>
              </div>
              <blockquote type=3D"cite">
                <div>On 24. 7. 2026 13:20, Ivan Zhakov wrote:<br>
                </div>
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">On Sat, 18 Jul 2026 at 18:27, Nathan
                    Hartman &lt;<a href=3D"mailto:[email protected]"=
 target=3D"_blank">[email protected]</a>&gt;
                    wrote: <br>
                    &gt; I&#39;m glad there&#39;s a good bit of housecleani=
ng
                    going on around here.<br>
                    &gt; We&#39;ve accumulated so much cruft over the years=
,
                    it makes my<br>
                    &gt; head spin. +1 to axe the ctypes bindings.<br>
                    <br>
                    Speaking of cleanups, another candidate comes to
                    mind: the BDB FS backend. I think now would be an
                    appropriate time to remove it:<br>
                  </div>
                </blockquote>
                <br>
                <br>
                We can&#39;t remove it before 2.0. It doesn&#39;t matter th=
at
                it&#39;s deprecated, it&#39;s part of the published 1.0 fea=
ture
                set.<br>
              </blockquote>
              <br>
              <br>
              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&#39;t remove for the same reason.<br>
              <br>
              -- Brane</div>
          </blockquote>
          <div><br></div></div></div></blockquote></div></blockquote><div>[=
...]=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blo=
ckquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>
          </div>
          <div>This was discussed previously [1] and we even received a
            bug report from FreeBSD that it doesn&#39;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.</div>
          <div><br>
          </div>
          <div>As Yasuhito point out,=C2=A0<span style=3D"color:rgb(34,34,5=
1);font-family:Selawk,Hack;font-size:13.3px;white-space:pre-line">SVN_FS_TY=
PE_BDB=C2=A0</span>is
            a public API which we need to keep. I didn&#39;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!).=C2=A0<span style=3D"background-color:transparent">=
In
              that case, we won&#39;t break anyone&#39;s code so anything t=
hat
              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&#39;t compile it in the first place).</span></div=
>
          <div><span style=3D"background-color:transparent"><br>
            </span></div>
          <div><span style=3D"background-color:transparent">Of course - we
              would force anyone using a BDB backend to do a
              dump-and-reload cycle as part of their upgrade.</span></div>
          <div><br>
          </div>
          <div>Provided my understanding above is correct, I&#39;m in favou=
r
            of removing BDB.</div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    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&#39;d have t=
o
    keep a stub that implements all exported functions, or we break the
    ABI.<br>
    <br></div></blockquote><div>
<div class=3D"gmail_quote"><div>=C2=A0</div><div>As far as I see libsvn_fs_=
base functions are not publicly exported. We have some BDB FS specific func=
tions [1]=20
in libsvn_fs, but they already stub to newer API and I agree we should=20
keep them.</div></div><div></div>

=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    In other words, even if we decide that removing BDB support isn&#39;t a=
n
    API violation, we can&#39;t do this in 1.15 because it&#39;s not a triv=
ial
    change of removing a directory and a couple lines from build.conf.<br>
    <br></div></blockquote><div>
<span>I agree and I don&#39;t think we should be doing anything about BDB i=
n 1.15 at this point (except for release notes). The proposed plan was abou=
t removing it in trunk / 1.16.</span>=C2=A0</div><br></div><div>[1]:=C2=A0<=
a href=3D"https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_=
fs/fs-loader.c?revision=3D1936528&amp;pathrev=3D1936528&amp;view=3Dmarkup#l=
786" target=3D"_blank">https://svn.apache.org/viewvc/subversion/trunk/subve=
rsion/libsvn_fs/fs-loader.c?revision=3D1936528&amp;pathrev=3D1936528&amp;vi=
ew=3Dmarkup#l786</a></div><br><span class=3D"gmail_signature_prefix">-- </s=
pan><br><div dir=3D"ltr" class=3D"gmail_signature">Ivan Zhakov</div></div>
</div>

--00000000000051619c06575d5d41--