On 3/19/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> Peter N. Lundblad writes:
> > Malcolm Rowe writes:
> > > On Fri, Mar 17, 2006 at 11:16:19PM +0100, Peter N. Lundblad wrote:
> > > > Malcolm Rowe writes:
> > > Even better! Looking around for any other evidence of the old behaviour,
> > > I see that (struct svn_wc_entry_t).checksum is currently documented as:
> > >
> > > /** base64-encoded checksum for the untranslated text base file,
> > > * can be @c NULL for backwards compatibility.
> > > */
> > > const char *checksum;
> > >
> > > (in include/svn_wc.h).
> > >
> > > I presume that's wrong, but I don't know what the best way to describe
> > > the checksum is - 'ASCII-encoded MD5 checksum'? Not very clear, imo.
> > >
> >
> > I think "hex md5 checksum" would be clear.
> >
>
> Bah! If we go back to the original problem, namely whether to
> preserve backwards compatibility for entries files created before
> early 2003. Earlier, I thought these were going to be auto-upgraded
> to use hex checksums instead of base64 ditto. Unfortunately, this is
> not the case because even if the entries file is rewritten, the
> contents of the checksum attribute is preserved asis.
>
> I guess I'll just check the length of the checksum entry field in svn
> _wc_transmit_textdeltas2 and punt if it is not the expected length of
> a hex checksum.
>
> Thoughts, anyone?
>
I really don't understand why we should support these old working
copies because they created BEFORE 1.0 was released. So we shouldn't
support it, if understand our compability policy correctly.
--
Ivan Zhakov
Received on Sat Mar 18 23:15:14 2006