You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2013/02/26 19:54:20 UTC
BDB deprecation (was: branch 1.8 or at least start making alpha releases?)
On 02/14/2013 10:23 PM, Branko Čibej wrote:
> On 15.02.2013 04:19, Branko Čibej wrote:
>> There are other new features in 1.8 that would benefit from having
>> potential users (and packagers) look at them sooner rather than later.
>> So I'm firmly in the "release alpha from trunk now" camp.
>
> And let's not forget that releasing anything but an alpha is blocking on
> the Serf 1.2 release, see
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4296
FIXED.
> and IMHO a resolution to the "deprecate Berkeley DB" discussion.
My current thoughts on this can be summarized like so:
* The appropriate time to stop supporting Berkeley DB is in the same release
for which existing FSFS will also have to dump/load. It is cruel to force
admins to endure the migration process twice -- possibly in successive
releases of Subversion -- and especially when one of those times is just for
a (possibly less-than-compelling) bit of a performance boost.
* That said, I'm okay with deprecating Berkeley DB today as a warning to
existing BDB users that change is a-comin', though the release notes should
(again) indicate that there's no reason to rush off and convert to FSFS
until an as-yet-undecided future revision forces the issue for *all*
Subversion users.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: BDB deprecation (was: branch 1.8 or at least start making alpha releases?)
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Feb 27, 2013 at 12:21 AM, Justin Erenkrantz
<ju...@erenkrantz.com>wrote:
> On Tue, Feb 26, 2013 at 1:54 PM, C. Michael Pilato <cm...@collab.net>wrote:
>
>> * The appropriate time to stop supporting Berkeley DB is in the same
>> release
>> for which existing FSFS will also have to dump/load. It is cruel to force
>> admins to endure the migration process twice -- possibly in successive
>> releases of Subversion -- and especially when one of those times is just
>> for
>> a (possibly less-than-compelling) bit of a performance boost.
>>
>
> I brought this up here in Portland with Brane et al - but, I'd be a tad
> concerned if we're going to make a dump/load *mandatory* for FSFS. Sure,
> we can advise a dump/load to get better performance, but I think we have
> shot ourselves in the foot with the client-side WC upgrade being mandatory.
> I hate the fact that 1.7 and 1.8 can't share WCs and force me to do 'svn
> upgrade'. As a developer testing trunk, this really blows...
>
I guess, Mike's point is that there are ideas floating around
to introduce a new FS2 interface in 1.9 or 1.10. That *might*
require a different backend implementation. Asking people to
migrate *twice*, i.e. BDB->FSFS in 1.8 / 1.9 and FSFS->"FSNG"
in 1.10 (even if only to add indexes etc.) would be at least
disappointing to admins. +1 on that rationale.
I also think that the transition from FSFS->"FSNG" needs to
be as smooth as possible.
> * That said, I'm okay with deprecating Berkeley DB today as a warning to
>> existing BDB users that change is a-comin', though the release notes
>> should
>> (again) indicate that there's no reason to rush off and convert to FSFS
>> until an as-yet-undecided future revision forces the issue for *all*
>> Subversion users.
>>
>
> +1. -- justin
>
That gives us the flexibility to phase out BDB on a short notice
in case we really have to.
+1
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: BDB deprecation (was: branch 1.8 or at least start making alpha releases?)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Feb 26, 2013 at 1:54 PM, C. Michael Pilato <cm...@collab.net>wrote:
> * The appropriate time to stop supporting Berkeley DB is in the same
> release
> for which existing FSFS will also have to dump/load. It is cruel to force
> admins to endure the migration process twice -- possibly in successive
> releases of Subversion -- and especially when one of those times is just
> for
> a (possibly less-than-compelling) bit of a performance boost.
>
I brought this up here in Portland with Brane et al - but, I'd be a tad
concerned if we're going to make a dump/load *mandatory* for FSFS. Sure,
we can advise a dump/load to get better performance, but I think we have
shot ourselves in the foot with the client-side WC upgrade being mandatory.
I hate the fact that 1.7 and 1.8 can't share WCs and force me to do 'svn
upgrade'. As a developer testing trunk, this really blows...
> * That said, I'm okay with deprecating Berkeley DB today as a warning to
> existing BDB users that change is a-comin', though the release notes should
> (again) indicate that there's no reason to rush off and convert to FSFS
> until an as-yet-undecided future revision forces the issue for *all*
> Subversion users.
>
+1. -- justin
Re: BDB deprecation
Posted by Branko Čibej <br...@wandisco.com>.
On 28.02.2013 09:59, Ben Reser wrote:
> On Wed, Feb 27, 2013 at 3:28 PM, Branko Čibej <br...@wandisco.com> wrote:
>> I propose we do this as follows:
>>
>> * Write a notice about deprecation and what it means in the release notes.
>> * Cause "svnadmin create" to issue a deprecation warning when a new
>> BDB repository is being created.
>> o this does not mean that calling the underlying svn_fs_create
>> should also emit a warning.
>>
>> The latter might have an effect on our test suite, alhough IIRC we only
>> invoke "svnadmin create" once during a test run.
> +1
If no-one objects by the end of this week, I'll implement it this way.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: BDB deprecation
Posted by Ben Reser <be...@reser.org>.
On Wed, Feb 27, 2013 at 3:28 PM, Branko Čibej <br...@wandisco.com> wrote:
> I propose we do this as follows:
>
> * Write a notice about deprecation and what it means in the release notes.
> * Cause "svnadmin create" to issue a deprecation warning when a new
> BDB repository is being created.
> o this does not mean that calling the underlying svn_fs_create
> should also emit a warning.
>
> The latter might have an effect on our test suite, alhough IIRC we only
> invoke "svnadmin create" once during a test run.
+1
Re: BDB deprecation
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/27/2013 06:28 PM, Branko Čibej wrote:
> On 26.02.2013 10:54, C. Michael Pilato wrote:
>> On 02/14/2013 10:23 PM, Branko Čibej wrote:
>>> On 15.02.2013 04:19, Branko Čibej wrote:
>>> and IMHO a resolution to the "deprecate Berkeley DB" discussion.
>> My current thoughts on this can be summarized like so:
>>
>> * The appropriate time to stop supporting Berkeley DB is in the same release
>> for which existing FSFS will also have to dump/load. It is cruel to force
>> admins to endure the migration process twice -- possibly in successive
>> releases of Subversion -- and especially when one of those times is just for
>> a (possibly less-than-compelling) bit of a performance boost.
>>
>> * That said, I'm okay with deprecating Berkeley DB today as a warning to
>> existing BDB users that change is a-comin', though the release notes should
>> (again) indicate that there's no reason to rush off and convert to FSFS
>> until an as-yet-undecided future revision forces the issue for *all*
>> Subversion users.
>
> I tend to agree. I propose we do this as follows:
>
> * Write a notice about deprecation and what it means in the release notes.
> * Cause "svnadmin create" to issue a deprecation warning when a new
> BDB repository is being created.
> o this does not mean that calling the underlying svn_fs_create
> should also emit a warning.
>
> The latter might have an effect on our test suite, alhough IIRC we only
> invoke "svnadmin create" once during a test run.
>
I've seen nothing but approval for my suggestions on this topic, which is
both encouraging and -- dare I say it? -- very consensus-like.
I like your specific suggestions here, Brane. Let's give others a little
more time to weigh in on the matter before action, but consider the above
the plan of record barring subsequent dissuasion.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: BDB deprecation
Posted by Branko Čibej <br...@wandisco.com>.
On 26.02.2013 10:54, C. Michael Pilato wrote:
> On 02/14/2013 10:23 PM, Branko Čibej wrote:
>> On 15.02.2013 04:19, Branko Čibej wrote:
>> and IMHO a resolution to the "deprecate Berkeley DB" discussion.
> My current thoughts on this can be summarized like so:
>
> * The appropriate time to stop supporting Berkeley DB is in the same release
> for which existing FSFS will also have to dump/load. It is cruel to force
> admins to endure the migration process twice -- possibly in successive
> releases of Subversion -- and especially when one of those times is just for
> a (possibly less-than-compelling) bit of a performance boost.
>
> * That said, I'm okay with deprecating Berkeley DB today as a warning to
> existing BDB users that change is a-comin', though the release notes should
> (again) indicate that there's no reason to rush off and convert to FSFS
> until an as-yet-undecided future revision forces the issue for *all*
> Subversion users.
I tend to agree. I propose we do this as follows:
* Write a notice about deprecation and what it means in the release notes.
* Cause "svnadmin create" to issue a deprecation warning when a new
BDB repository is being created.
o this does not mean that calling the underlying svn_fs_create
should also emit a warning.
The latter might have an effect on our test suite, alhough IIRC we only
invoke "svnadmin create" once during a test run.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com