Blair Zajac <blair@orcaware.com> writes:
>> I have the same opinion as Dave. Karl, can things be structured such
>> that the protocol-specific capabilities are sent only for the relevant
>> protocols, and the global Subversion-specific capabilities are always
>> sent?
>
> Shouldn't we have 2 sets of capabilities? Svn and protocol specific?
>
> Do we want to use filtering? Say a 1.6 client has svndiffN and sends
> it to a 1.5 server, then thee 1.5 server won't filter it out and pass
> it to the start-commit script.
>
> Unless I'm misunderstanding something how the new capabilities work.
The larger issue of clearly separating protocol capabilities from
functionality capabilities is not something I want to address now
(would delay 1.5, etc).
But we can still make sure the 'start-commit' hook hears consistent
capabilities independent of RA layer. The way to do this, I think,
is to have the client continue sending every capability it knows about
(be liberal in what you send), while the server filters out those it
doesn't care about (be conservative in what you keep).
Of course, "those it doesn't care about", really means "those that
writers of start-commit hooks shouldn't care about", since
start-commit is the only audience for client->server capabilities at
the moment. But if later on internal server code needs to know client
functionality, we can just start remembering more of the capabilities
the client told us.
The important thing is that the client send everything it knows at all
times, so that server upgrades are likely to be backwards-compatible
(and even bring in new functionality) without any client upgrade being
necessary.
I have done the above in r27656.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 7 17:43:58 2007