Re: base64 encoded md5 digests in entries file (was: Re: export, checkout, commit performance)
On 3/19/06, Peter N. Lundblad <email@example.com> 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.
Received on Sat Mar 18 23:15:14 2006
This is an archived mail posted to the Subversion Dev