Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Daniel Shahaf <danielsh <at> elego.de>
Subject: Re: Ev2 symlinks
Newsgroups: gmane.comp.version-control.subversion.devel
Date: Friday 28th June 2013 04:20:34 UTC (over 3 years ago)
Greg Stein wrote on Thu, Jun 27, 2013 at 22:25:48 -0400:
> On Thu, Jun 27, 2013 at 8:40 PM, Daniel Shahaf  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 
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
 
CD: 3ms