> -----Original Message-----
> 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.
Bert
Received on 2010-08-24 17:13:05 CEST