Greg Stein <gstein@lyra.org> writes:
> 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.
This specific instance isn't what's important; the general question is
still valid: Will we someday be in a situation where we want to add a
feature that is not compatible with older clients (or servers), and
where merely discovering the incompatibility may be difficult if
feature negotiation isn't available?
I'm not saying the answer is definitely "yes". Perhaps Apache+DAV
give us so much flexibility that we'll always be able to improvise a
case-specific negotiation for any given incompatible change.
But if the answer *is* yes, or is probably yes, then we need to make
sure the initial Subversion ships with a predefined way to detect such
situations.
Is there an extensible DAVvy way to do this already? Would we have to
design our own sub-protocol?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:07 2006