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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
