Tim Peters wrote:
> The best idea is to clean it up so that it makes good sense. There's
> lots of historical cruft in the ZODB code base that doesn't make much
> sense anymore.
Hm. To me, this would mean to get rid of the test suites in
src/ZODB/tests and move checks which they do but the test suites in
src/persistent/tests don't do to the latter. I'll have a go at that
later in the week.
> "Old" news will become "new" news again, when the next micro release
> in the ZODB 3.5 line is made.
Oh, I meant "old" as in "telling about old changes", not "having been
read a long time ago".
> BTW, merges to NEWS-like files generally don't work well across
> branches. What to do instead:
> - Do the merge.
> - Do "svn revert NEWS.txt" to throw away the botched merged on that
> single file.
> - Edit NEWS.txt by hand, inserting branch-appropriate NEWS for what
> changed in the rest of the merge. Usually this amounts to just
> copying paragraphs from one NEWS.txt to another, changing version
> numbers in an obvious way.
That's what I'd do after thinking about it some more, anyway.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org