Greg Stein wrote on Fri, Jun 28, 2013 at 02:49:01 -0400:
> On Fri, Jun 28, 2013 at 1:59 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Greg Stein wrote on Fri, Jun 28, 2013 at 01:25:42 -0400:
> >> On Fri, Jun 28, 2013 at 1:19 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> >> >...
> >> > So, to be explicit: calling add_symlink() when driving the FS commit
> >> > editor is a bug;
> >> Of course not. The FS commit editor knows how to represent a symlink
> >> within the FS. (however the FS design changes over time)
> > Okay. Suppose Ev2 is released in 1.9 and svn:special=blockdev in 1.10.
> > An app is built against libsvn_fs-1.9 and ran with libsvn_fs-1.10. The
> > app calls svn_editor_add_file(svn:special='*', contents="blockdev ...").
> > At what point does this call get converted to svn_editor_add_blockdev()?
> I don't understand why a 1.9 app would think to use contents="blockdev". ??
That's part of our compatibility rules.
We defined a "blockdev" special in 1.10, so when 1.10 clients checkout
a file that has svn:special=blockdev, they create a block device on
disk; when 1.9 clients checkout it, they create a plain file with
contents "blockdev $args". The same works in reverse: 1.10 clients can
create a versioned blockdev by (presumably) 'mknod && svn add', while
1.9 clients can create a versioned blockdev by doing 'printf "%s %s"
blockdev $args >file && svn add file && svn ps svn:special yes file'.
That's how you create versioned symlinks on windows.
So, in short, if you accept that 1.10 may define a new svn:special
value, you need to specify what happens when a 1.9 client tries to
create a file with that svn:special value, using 1.9 APIs --- that is my
> It doesn't seem that a 1.9 system could ever add such a node. It might
> be able to move/copy a node that it checked out from a 1.10 server
> (but has no real representation for).
See above. We support creating symlinks on windows and in general we
support creating special files on platforms that can't create them as
actual symlinks or block devices.
> svn:special is just a trick. If we see it, then we know something else
> was intended. Ev2 attempts to remove those tricks. But when you butt
> up against older code, then the trick needs to be played again.
Right, right. My point is that API compatibility means that
svn_editor_add_file() is a point where you may run against older code
(where "older" means "1.9, but 1.10 has been released with blockdevs").
> We can continue playing tricks with svn:special for older clients. We
> can even invent "svn:ev2-secret-node-serialization" if we want. But I
> believe that we have ample tools in our chest to clean up the APIs by
> making symlinks first class objects (and if/when other types in the
Received on 2013-07-01 14:48:38 CEST