"Bert Huijben" <[email protected]> writes: >> From: Philip Martin [mailto:[email protected]] >> Sent: dinsdag 24 augustus 2010 16:58 >> To: Bert Huijben >> Cc: 'Julian Foad'; 'Bert Huijben'; [email protected] >> Subject: Re: svn commit: r988074 - in >> /subversion/trunk/subversion/tests/cmdline: svntest/wc.py >> upgrade_tests.py >> >> "Bert Huijben" <[email protected]> writes: >> >> >> -----Original Message----- >> >> From: Julian Foad [mailto:[email protected]] >> >> >> >> If, instead, we construct each the PRISTINE table entry at the point >> >> where we're converting an entry from the entries file, then we can >> >> calculate both checksums on the fly, and we can store both of them in >> >> the new DB row(s). That's true even for those few pristines that don't >> >> have any checksum in the 'entries' file. >> >> Or we could modify the current code that constructs the pristine table >> to update the base/working nodes as well. >> >> > 1.0.0 working copies have no checksums at all if I remembered >> > correctly and we certainly have to upgrade those WCs. Same recipe >> > for all files with a revert base. >> >> Well, upgrade_tests 7 (basic_upgrade_1_0) passes in single-db and it >> verifies the pristine text post-upgrade using MD5. When I look in the >> tarball I see checksums in the entries file. >> >> Revert bases won't have a checksum, but until we have NODE_DATA there >> is nowhere to put a revert base checksum. > > Sure there is. > If you have a normal replaced file you can have one checksum in BASE_NODE > (for the original) and one in WORKING_NODE (for the copy that replaced the > original). Only when you delete that working node, you have no place to > store it if that copy happens to be the child of the real copy.
Ah yes, of course. That's one of the things we could fix by updating base/working while construction pristine. We need lots more upgrade regression tests. -- Philip
