[ZODB-Dev] RE: RE: RE: PersistentMapping

Tim Peters tim at zope.com
Tue Nov 22 15:04:32 EST 2005


[Thomas Lotze]
> Tests... there are test suites for PersistentMapping both in
> src/ZODB/tests/testPersistentMapping.py (which is the one that checkin
> message talked about) and one in src/persistent/tests/test_mapping.py
> (which I added when I found test_list.py, but no mapping tests in that
> place). Now there are two test suites for persistent mapping, just as
> there are for lists. In the case of lists it's even clearer than for
> mappings that the duplication is unnecessary as the test code is more or
> less the same. The tests in src/ZODB/tests were touched more recently
> than those in src/persistent/tests according to svn, but IMO it's more
> obvious to test lists and mappings close to where they are defined. What
> to do about this?

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.

>> Looks like the 3.5 branch got overlooked.  Merging rev 38076 from 3.4
>> branch to 3.5 branch would be fine.

> This yields a large conflict in 3.5's NEWS.txt. Should I just leave it
> untouched and not modify old news?

"Old" news will become "new" news again, when the next micro release in the
ZODB 3.5 line is made.  3.5.1 is current.  All changes made now on the 3.5
branch will eventually show up in a 3.5.2 release, and NEWS.txt on the 3.5
branch should be changed to record those changes as they're made (the idea
that a "release manager" is going to dig thru ZODB history to do this at the
last second before a release is a fantasy -- won't happen).

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.



More information about the ZODB-Dev mailing list