Re: Proposal: Support for versioning symlinks and other special files.

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?

> 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.

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.

If I implement character/block devices, they will be disabled by
default, needing a config option to enable them as per ghudson's
suggestion.

-Josh

-- 
It's easy to solve the halting problem with a shotgun.   :-)
             -- Larry Wall in <199801151836.KAA14656@wall.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org