On Fri, Jun 28, 2013 at 07:20:34AM +0300, Daniel Shahaf wrote: > 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
In second thought, this just moves the problem: the wc layer would want to call add_symlink() during a commit. But I'd like to avoid the ambiguity still: either add_symlink() or add_file(svn:special=yes), not both; either add_blockdev() or add_special(), not both. Not sure how we can avoid this... > 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
