Josh Pieper wrote:
>kfogel@collab.net wrote:
>
>
>>Josh Pieper <jjp@pobox.com> writes:
>>
>>
>>>support for non-UNIX like systems yet. Finally, I believe a new type
>>>of entry in the WC entries file is necessary, perhaps "special" or
>>>something similar. It would allow the WC code to determine when a
>>>normal file has been replaced with a special file or vice versa.
>>>Changes between different types of special files can be handled using
>>>the normal translation framework.
>>>
>>>
>>If we're having a new type of entry in the WC entries file anyway, do
>>we also want to have a new "svn:" property? If there are two
>>indicators of the same thing, then they can get out of sync; it seem
>>like asking for trouble, maybe?
>>
>>
>
>Except that you need some way in the repository to indicate it as
>well. We could introduce a new node kind into the repository, but I
>figured just doing it in the WC would be less invasive and would
>introduce one less incompatibility between 1.1 and 1.0. I'm open to
>debate though. Would it be better to add a new node type to the
>repository and use it there and in the WC, or to have a svn: property
>along with a new WC entry type and no changes to the repository?
>
>
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.
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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 29 07:46:47 2004