On Thu, Jun 27, 2013 at 8:40 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Greg Stein wrote on Thu, Jun 27, 2013 at 20:33:39 -0400:
>> On Thu, Jun 27, 2013 at 8:01 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
>> > Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
>> >> On 27.06.2013 21:16, Greg Stein wrote:
>> >> > On IRC, Branko noted:
>> >> > on the subject of ev2 api, i'm wondering if add_symlink and
>> >> > alter_symlink should really be there. it looks like special-casing on
>> >> > one type of special node
>> >> >
>> >> >
>> >> > There is *only* one type of special node. There are no plans for any
>> >> > other type of special node.
>> >> Yes, there are. And not only in my head, either. :)
>> >> I just haven't got around to starting a design doc.
>> > And the question is: once someone invents a kind of svn:special node
>> > (besides "link"), how would Ev2 represent it?
>> Add more APIs to Ev2. Since it is not a vtable-based API, extension is
>> very easy.
> So if Ev2 is released in 1.9 and we invent a new svn:special kind in
> 1.10, you need to have a 1.10 client *and* server in order to use it.
That doesn't follow. There is a difference between APIs and
serialization. We can surface new types in the API, and serialize in
backwards-compatible ways. A 1.10 client can talk about (say) block
devices all over the place, but serialize it over the wire as
svn:special to a 1.9 server.
wc-1.0's model of "is this file special?" was a horrible model.
WC-NG/wc_db/Ev2 fix that. They surface the type explicitly.
But it can all be serialized via svn:special if you want. Until the FS
changes, there is no need to change the wire serialization. But it
*is* (and *has been*) very helpful to change the coding model.
> That's a #lose, sorry. The way svn:special works now means even 1.0
> clients and servers can talk about any svn:special kind we might add
> whenever. I see no compelling reason to break that functionality.
You're mixing API expression and serialization.
Received on 2013-06-28 04:26:21 CEST