Greg Stein wrote on Thu, Jun 27, 2013 at 22:25:48 -0400:
> 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.
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
Received on 2013-06-28 06:21:25 CEST