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

Re: feature negotiation?

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2002-02-13 02:03:24 CET

On Tue, Feb 12, 2002 at 04:24:43PM -0800, Greg Stein wrote:
> On Tue, Feb 12, 2002 at 04:42:18PM -0600, Ben Collins-Sussman wrote:
> >
> > I was talking with someone on #svn, and heard a story about how he had
> > used a very old (0.6) svn client to try and update his working copy.
> > The server then sent binary diffs (a relatively new-ish feature) that
> > ended up trashing his working copy.
> >
> > My question is: do we need client/server feature negotiation?
>
> We have it already. The server only sends svndiff data when the client sends
> a specific header. In other words, the client said "here is what I have, if
> you can give me a diff against that, then great. otherwise, just send me a
> fulltext of X." On the other side, the server sees the header and can choose
> to send a diff, or it can send the fulltext. If the server doesn't know
> about the headet, then it will just be sending the fulltext because it
> doesn't know what to diff against.
>
> So the fact that the person's WC got garbled is a bug somewhere. Not a lack
> of feature negotiation.
>
We do it, but only one way. The server looks at the rev, and can generate the
svndiff, but there is no way for the client to say "I don't know what svndiff
is, send me the fulltext".

Or do we? and the client just always said that it understood svndiff's when
before it did?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • application/pgp-signature attachment: stored
Received on Sat Oct 21 14:37:07 2006

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.