Greg Stein wrote on Thu, Jun 27, 2013 at 22:25:48 -0400: > 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.
Is it? Suppose 1.10 adds block devices. The 1.10 libsvn_wc will need to implement handling of block devices in two places: in add_blockdev() for use with 1.10 servers, and in add_file()-conditioned-upon-svn:special for use with 1.9 servers. That creates ambiguity. It's also a kind of bug that we are liable miss (pop quiz: who ran 'make check' with 1.7 client and 1.8 server, or 1.8 client and 1.7 server, during the soak?). How about removing svn_editor_add_symlink() but retaining svn_editor_cb_add_symlink_t()? The libsvn_delta/editor.c code can arrange to dispatch to the add_symlink() callback if it has been provided and to add_file() otherwise. That way the amibiguity on the driver's side is removed, and the consumer's code is clean too (it has a separate add_symlink() entry point). Daniel