Daniel Rall wrote:
> On Tue, 06 Nov 2007, David Glasser wrote:
>
>> On 11/6/07, Karl Fogel <kfogel@red-bean.com> wrote:
>>
>>> 3) RA-dependent inconsistency in capability reporting.
>>>
>>> This is a minor nit, sort of related to (2). Both ra_local and
>>> ra_dav (neon and serf) pass the same set of capabilities to
>>> 'start-commit', namely "log-revprops,depth,mergeinfo" (the order
>>> might change, but the set is the same). However, ra_svn sends:
>>>
>>> "edit-pipeline,svndiff1,absent-entries,depth,mergeinfo,log-revprops"
>>>
>>> You can imagine why: it's largely an accident of implementation
>>> and the fact that ra_svn was already transmitting capabilities
>>> before the other RA layers got into the game.
>> Well, sort of. It's also the fact that some of these (edit-pipeline
>> especially, and svndiff1 to some degree) are really ra_svn-protocol
>> specific. They aren't properties of the *Subversion* client or server
>> (like the new caps are); they're properties of the *ra_svn protocol*
>> client or server. I don't think that start-commit should see them any
>> more than they should see User-Agent strings or whether mod_gzip was
>> used or something.
>
> 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.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 6 20:31:11 2007