"Bert Huijben" <bert_at_qqmail.nl> writes:
>> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
>> Sent: dinsdag 24 augustus 2010 16:58
>> To: Bert Huijben
>> Cc: 'Julian Foad'; 'Bert Huijben'; dev_at_subversion.apache.org
>> Subject: Re: svn commit: r988074 - in
>> /subversion/trunk/subversion/tests/cmdline: svntest/wc.py
>> upgrade_tests.py
>>
>> "Bert Huijben" <bert_at_qqmail.nl> writes:
>>
>> >> -----Original Message-----
>> >> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
>> >>
>> >> 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
Received on 2010-08-24 17:35:09 CEST