Josh Pieper wrote:
>Branko ??ibej wrote:
>
>
>>1.0 clients must be able to talk to 1.1 servers, and unless the server
>>can know in advance not to send the new node kind values to a client
>>that doesn't understand them, you can't add new node types. I suppose
>>the server should be able to figure it out, though -- I think we have a
>>mechanism for this in both ra_dav and ra_svn.
>>
>>
>At what point in the connection process does the server know that it
>is talking to an old client and what is the API mechanism for
>determining this?
>
>
I'm not very familiar with the RA layers; I think ra_dav can set a
property on the custom reports to determine if the client understands
extended options, and ra_svn has capabilities.
>>If that's the case, then using a new node kind is much cleaner. However,
>>I object to adding /five/ new node kinds where one will do quite nicely.
>>In general, I find the patch adds way too much system-specific logic
>>into the API (not talking about system-specific code in the
>>implementation, of course). The API should be as neutral as possible.
>>There are "special" file types on systems other than Unix, and the same
>>logic should handle them all.
>>
>>
>
>Ok, I believe only three API changes were introduced:
>
> 1. Adding the 'special' flag to svn_subst_copy_and_translate
>
> 2. Adding the svn:special property.
>
> 3. Increasing the number of svn_node_kind_t's.
>
>I assume you are talking about 3, in which case I agree.
>
>
Yup.
>After considering the feedback, I think a workable solution would be
>to introduce just one new type, svn_node_special, and have it be
>stored in the repository that way as well doing away with the
>svn:special property. The server could translate this to a
>svn_node_file for 1.0 clients. Then, the only system specific logic
>would not be exported directly in any API, since it would consist of
>just the stuff necessary to create and read the special files.
>
>
Seems reasonable. It would also be nice if the change to
svn_subst_copy_and_translate were a bit more generic. That is, instead
of adding another boolean flag, you could pass in the node type, or
maybe combine the various bools into a bit mask. Both would leave room
for future extensions.
>If I implement character/block devices, they will be disabled by
>default, needing a config option to enable them as per ghudson's
>suggestion.
>
>
+1
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 30 00:28:16 2004