Karl Fogel wrote:
> Stefan Küng <tortoisesvn@gmail.com> writes:
>> May I suggest adding a new API which only detects whether the server
>> supports a certain feature?
>
> I think this is what the new capabilities-discovery API added in
> r27168 does.
>
>> Something like:
>> enum supportedfeature
>> {
>> mergetracking, // supports merge tracking
>> loglimit // supports the --limit switch for logs
>> }
>>
>> enum supportstate
>> {
>> notsupported, // feature is not supported
>> partlysupported,// feature is not supported by server, but client
>> has workaround
>> fullysupported // server supports the feature completely
>> }
>>
>> supportstate svn_client_check_server_capability(supportedfeature feature);
>>
>> Then clients could ask the server what it is capable of and then
>> decide whether they want to offer a certain feature to the user or
>> not.
>
> The current API only says boolean "yes" or "no" that the server
> supports the feature, but I'm not sure what the point of the third
> state would be. After all, if the client has a workaround, it knows
> that, and can decide whether or not to use it. IOW, that's not a
Not quite: we're talking about the Subversion *library* here. And a
client doesn't necessarily know whether the library has a workaround (it
usually has (log --limit), but not always (locking)). That's what the
third state would be for: if the library has a workaround, it would
change the state from 'notsupported' to 'partlysupported'.
The client can then decide on that state what to do.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 22 18:06:05 2007