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
original question.
> 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
> future).
>
> Cheers,
> -g
Received on 2013-07-01 14:48:38 CEST