On Thu, Jun 27, 2013 at 8:40 PM, Daniel Shahaf <danie...@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 <danie...@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. Cheers, -g
