Re: State of BDB FS backend
Daniel Sahlberg <[email protected]> Tue, 28 Jul 2026 14:09:47 +0200
| Newsgroups | gmane.comp.version-control.subversion.devel |
|---|---|
| Message-ID | <CAMHy98NuBFs1OjWmecvVh-scUy8EWYzJRRzHUy0itQjb-2JmMw@mail.gmail.com> |
--000000000000e8c9300657aab7bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Ivan Zhakov <[email protected]> w= rote: >> > >> > On Fri, 24 Jul 2026 at 15:06, Branko =C4=8Cibej <[email protected]> wro= te: >> >> >> >> On 24. 7. 2026 13:57, Daniel Sahlberg wrote: >> >> >> >> Den fre 24 juli 2026 kl 13:30 skrev Branko =C4=8Cibej <[email protected]= rg>: >> >>> >> >>> 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 f= or >> 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 Futats= uki >> 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 s= tub >> 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.1= 5 >> 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-l= oader.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 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 no= t > mention it in the announcement - either something is supported or it is N= OT > 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 =C4=8Cibej <[email protected]> Does this satisfy your concerns? Anyone else? Cheers, Daniel --000000000000e8c9300657aab7bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare= nt">Den fre 24 juli 2026 kl 21:03 skrev Daniel Sahlberg <<a href=3D"mail= to:[email protected]">[email protected]</a>>:</span>= </div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><span style= =3D"background-color:transparent">Den fre 24 juli 2026 kl 18:52 skrev Natha= n Hartman <<a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a>>:</span></div><div class=3D"gmail_quote"><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jul 24, 2026 at 11= :52=E2=80=AFAM Ivan Zhakov <<a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>> wrote:<br> ><br> > On Fri, 24 Jul 2026 at 15:06, Branko =C4=8Cibej <<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> >><br> >> On 24. 7. 2026 13:57, Daniel Sahlberg wrote:<br> >><br> >> Den fre 24 juli 2026 kl 13:30 skrev Branko =C4=8Cibej <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>:<br= > >>><br> >>> On 24. 7. 2026 13:23, Branko =C4=8Cibej wrote:<br> >>><br> >>> On 24. 7. 2026 13:20, Ivan Zhakov wrote:<br> >>><br> >>> On Sat, 18 Jul 2026 at 18:27, Nathan Hartman <<a href=3D"ma= ilto:[email protected]" target=3D"_blank">[email protected]</= a>> wrote:<br> >>> > I'm glad there's a good bit of housecleaning goin= g on around here.<br> >>> > We've accumulated so much cruft over the years, it ma= kes my<br> >>> > 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> >>><br> >>><br> >>><br> >>> 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.<br> >>><br> >>><br> >>><br> >>> Just to be clear: the existence of the BDB back-end is equival= ent to a public API. We have many deprecated public APIs that we can't = remove for the same reason.<br> >>><br> >>> -- Brane<br> >><br> >><br> > [...]<br> >><br> >> 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 Fut= atsuki 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.<br> >><br> >> 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_b= ase only implement a filesystem API reachable via the fs loader (this is wa= y 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 u= nder 1.14 will still compile under 1.16, but it it would not be able to loa= d the BDB FS backend (just as if you didn't compile it in the first pla= ce).<br> >><br> >> Of course - we would force anyone using a BDB backend to do a dump= -and-reload cycle as part of their upgrade.<br> >><br> >> Provided my understanding above is correct, I'm in favour of r= emoving BDB.<br> >><br> >><br> >><br> >> 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.<br= > >><br> ><br> > 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 stu= b to newer API and I agree we should keep them.<br> ><br> >><br> >> In other words, even if we decide that removing BDB support isn= 9;t an API violation, we can't do this in 1.15 because it's not a t= rivial change of removing a directory and a couple lines from build.conf.<b= r> >><br> > 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.<br> ><br> > [1]: <a href=3D"https://svn.apache.org/viewvc/subversion/trunk/subvers= ion/libsvn_fs/fs-loader.c?revision=3D1936528&pathrev=3D1936528&view= =3Dmarkup#l786" rel=3D"noreferrer" target=3D"_blank">https://svn.apache.org= /viewvc/subversion/trunk/subversion/libsvn_fs/fs-loader.c?revision=3D193652= 8&pathrev=3D1936528&view=3Dmarkup#l786</a><br> ><br> > --<br> > Ivan Zhakov<br> <br> <br> This was discussed several times before, such as [1], [2].<br> <br> Arguments in favor of removing BDB:<br> <br> (1) It has been deprecated for a long time.<br> <br> (2) AFAICT most devs are no longer testing BDB so maybe it works, or<br> maybe it bitrotted.<br> <br> (3) Last I checked, some kind of registration was needed to get the<br> official sources?<br> <br> (4) It might not have many (or any) users anymore.<br> <br> Arguments against removing it:<br> <br> (1) API guarantees...<br> <br> (2) Questions about what's involved in actually ripping it out.<br> <br> (3) Users with BDB-backed repos would need to dump and load them<br> BEFORE we remove it...<br> <br> ...and that means we need to give very clear, advance notice.<br> <br> So this is my suggestion: For now, let's start by making the<br> announcement together with the 1.15.0 release. I suggest to put the<br> announcement in the 1.15 release notes as well as creating a separate<br> news item for it. In the announcement, we won't commit to removing it<b= r> by a specific date or release. We'll just convey that its removal is<br= > being planned and may be imminent.<br> <br> After the announcement is made, Let's take as long as we need to<br> figure out the issues of API guarantees, how/what to remove, etc.<br> There's no rush to do the actual removal, but I think the announcement<= br> needs to give users as much time as possible.<br> <br> Proposed initial draft of announcement:<br> <br> [[[<br> <br> IMPORTANT NOTICE: Subversion's Berkeley DB repository backend (BDB)<br> has been deprecated since Subversion 1.8 (13 years) and is planned for<br> REMOVAL with a future Subversion release line. It will not be possible<br> to access BDB-backed Subversion repositories after upgrading to a<br> Subversion release that no longer supports it. The Subversion 1.15.x<br> release line may be the last minor release line to support the BDB<br> backend.<br> <br> Users who have BDB-backed Subversion repositories should upgrade them<br> to the newer FSFS backend as soon as possible to avoid disruption.<br> FSFS has been the default since Subversion 1.2 (21 years). This<br> requires to "dump" the repository using a Subversion release that= <br> supports BDB and then to "load" the repository using any recent<b= r> Subversion release. For details, please see the FAQ entry "How do I<br= > convert my repository from using BDB to FSFS or from FSFS to BDB?":<br= > <a href=3D"https://subversion.apache.org/faq.html#bdb-fsfs-convert" rel=3D"= noreferrer" target=3D"_blank">https://subversion.apache.org/faq.html#bdb-fs= fs-convert</a><br> <br> ]]]<br> <br> Commenting on my own initial draft:<br> <br> Instead of sending them to the FAQ, maybe we'd want to write clear<br> backup/dump/load instructions directly in the announcement?<br> <br> Do we want to point out that the BDB backend might not be as well<br> tested as FSFS these days?<br> <br> WDYT?<br></blockquote><div><br></div><div>I think this is a good plan. I wo= uld prefer to keep the announcement as short as possible and link to the FA= Q, improving that if needed.</div><div><br></div><div>I seem to remember th= at 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 announcem= ent - either something is supported or it is NOT supported.</div><div><br><= /div><div>Cheers,</div><div>Daniel</div><div><br></div><div>=C2=A0</div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex"> <br> [1] "Berkely DB precompiled for Windows"<br> =C2=A0 =C2=A0 Posted to dev@ on 26 Sept 2024<br> =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.apache.org/thread/m4o5l9rntc9= 8y6s8wrhsn329by9bhr19" rel=3D"noreferrer" target=3D"_blank">https://lists.a= pache.org/thread/m4o5l9rntc98y6s8wrhsn329by9bhr19</a><br> =C2=A0 =C2=A0 Continued here (disconnected in the archives):<br> =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.apache.org/thread/99zo1wq0031= 09p06dt1tcxyzd7cyyw32" rel=3D"noreferrer" target=3D"_blank">https://lists.a= pache.org/thread/99zo1wq003109p06dt1tcxyzd7cyyw32</a><br> =C2=A0 =C2=A0 and here:<br> =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.apache.org/thread/7plrvmhk3c0= jvhkq1tfwds8j4tmlgslc" rel=3D"noreferrer" target=3D"_blank">https://lists.a= pache.org/thread/7plrvmhk3c0jvhkq1tfwds8j4tmlgslc</a><br> <br> [2] "Removing BDB support from 1.15"<br> =C2=A0 =C2=A0 Posted to dev@ on 18 Mar 2025<br> =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.apache.org/thread/kn0yw4f8p6t= n2tzq4obr5r5v609g6g1m" rel=3D"noreferrer" target=3D"_blank">https://lists.a= pache.org/thread/kn0yw4f8p6tn2tzq4obr5r5v609g6g1m</a><br> <br> Cheers,<br> Nathan<br></blockquote></div></div></blockquote><div><br></div><div>It has = been over four days and no further discussion on this thread so I'd lik= e to try making a summary. The last technical comment was made by Ivan answ= ering Brane's concerns about modifying public API ("<span style=3D= "background-color:transparent">libsvn_fs_base functions are not publicly ex= ported. We have some BDB FS specific functions in libsvn_fs, but they alrea= dy stub to newer API and I agree we should keep them").</span></div><d= iv><span style=3D"background-color:transparent"><br></span></div><div><span= style=3D"background-color:transparent"><a class=3D"gmail_plusreply" id=3D"= plusReplyChip-0" href=3D"mailto:[email protected]" tabindex=3D"-1">@Branko = =C4=8Cibej</a>=C2=A0Does this satisfy your concerns?<br></span></div><div><= span style=3D"background-color:transparent"><br></span></div><div><span sty= le=3D"background-color:transparent">Anyone else?</span></div><div><span sty= le=3D"background-color:transparent"><br></span></div><div><span style=3D"ba= ckground-color:transparent">Cheers,</span></div><div><span style=3D"backgro= und-color:transparent">Daniel</span></div><div><span style=3D"background-co= lor:transparent"><br></span></div><div><br></div><div><br></div></div></div= > --000000000000e8c9300657aab7bd--