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

Re: [Issue 1715] Checksums in the rA layer

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-07-03 22:40:18 CEST

On Sun, 27 Jun 2004, Greg Hudson wrote:

> On Sun, 2004-06-27 at 04:52, Peter N. Lundblad wrote:
> > On Sat, 26 Jun 2004, Greg Hudson wrote:
> >
> > > On Sat, 2004-06-26 at 14:38, Peter N. Lundblad wrote:
> > > > - I'm sending text deltas and no checksums. Should I? (Same question also
> > > > applies to DAV. I will be consistent about this.)
> > >
> > > get_file has no checksums, so I'd say no, it's probably not worth it.
> > > Others might disagree, though.
> > >
> > Both the protocol file and the code look like get-file indeed has a
> > checksum. What do I miss?
> I guess it does. I looked at svn_ra.h and saw no checksum. (Which just
> means the ra_svn client code takes care of checking it, as it turns out,
> but I didn't think that far.)
> So, yes, I guess you want a checksum.
Hmmm... Studying it more carefully, I'm not sure again. For get_file, the
checksum check is internal to the protocols and not exposed to the client.
That works because the contents stream through the RA implementation in
fulltext. But in the case of get_file_revs, the RA implementation just
passes the delta to the client. Then, in the delta editors, the checksum
is also passed to the client.

Do you think it is useful to change get_file_revs to provide the checksum
to the caller? I mean, how necessary is the checksum in this case? We
expect the network traffic to be correct, don't we?

I think this is the only way to get checksum verification on this call.
Else we have to apply the text deltas once more just to get the fulltext.

I think I need advise here...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 3 22:28:57 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.