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 <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
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
Received on 2013-06-28 06:53:04 CEST