[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: base64 encoded md5 digests in entries file (was: Re: export, checkout, commit performance)

From: Ivan Zhakov <chemodax_at_gmail.com>
Date: 2006-03-18 23:14:57 CET

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

This is an archived mail posted to the Subversion Dev mailing list.