> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: dinsdag 24 augustus 2010 10:40
> To: Bert Huijben
> Cc: 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_vmoo.com> writes:
>
> >> * subversion/tests/cmdline/upgrade_tests.py
> >> (text_base_path): Restore MD5 support removed in r960036.
> >
> > I think the real fix would be to upgrade to SHA1 (and add the
> > mapping in the pristines table) in the upgrade step. I expected that
> > this was already handled?
>
> Yes, that needs to happen, and no, it doesn't happen yet. The new
> code stores SHA1 on checkout/update but the upgrade code simply copies
> the MD5 and doesn't do MD5 to SHA1 conversion. I discussed this with
> Julian on IRC yesterday, the plan is to remove the MD5 support
> eventually.
>
> There are two cases to consider, upgrade from 1.6 to latest and
> upgrade from older 1.7 to latest. For the older 1.7 upgrade we can
> simply use the PRISTINE table to replace the MD5 with the
> corresponding SHA1 in the bump_to_19 code.
>
> The 1.6 upgrade is a bit harder. We can do the text-base to pristine
> before doing the entries file, so that the PRISTINE table is
> available, but the table is not currently indexed on MD5. As there is
> now only one table per wc it might be too slow if there are lots of
> files. We may need an MD5 index, as part of PRISTINE or separate,
> just for the duration of the upgrade. The bump_to_19 code can do the
> MD5 to SHA1 conversion before switching to single-db, the table is
> smaller and may not need an MD5 index (and the bump_to_19 code simply
> isn't as important as the 1.6 upgrade code).
In the old entries format we only kept one checksum, while we can have two
pristine files, so just keeping it as MD5 can't solve all the issues.
But we can't just assume that we never see a collision with MD5 over an
entire tree.. or we wouldn't have switched to SHA1 in the first place.
Maybe we should use a somewhat broader structure then just a single (or
dual) svn_wc_entry_t to keep the state while upgrading. This can then
contain things like the SHA1 checksums and other values that can't be stored
in just the entries.
Just looking up a node by its MD5 in the pristines table will not resolve
the collision problems :(
Bert
Received on 2010-08-24 11:38:00 CEST