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

Re: [PATCH] [Issue 1715] svn protocol extensions

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-06-27 18:31:34 CEST

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.

> > If the API allows early cancellation (i.e. the consumer function can
> > cancel), then it's necessary. Otherwise, it's overkill. I don't think
> > your current API allows early cancellation, nor is it really important
> > for it to do so.

> The callback might return an error. For example, the blame command checks
> for cancelation for each call of the callback. Might be good if you by
> mistake say "svn blame -r1:HEAD" and it takes a long time. But maybe you
> can just close the connection then?

Well, if you do a get_log and return an error from the log receiver,
your ra session is also screwed up. (Possibly over ra_dav as well as
ra_svn, but I'd have to check.) So yes, I'd say the caller has to close
the connection in this case. Adding the asynchronous cancellation
support necessary to keep the connection working is a lot of complexity
for a case no caller is likely to care about.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 27 18:32:26 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.