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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-02-28 18:38:15 CET