Greg Stein wrote on Fri, Jun 28, 2013 at 02:49:01 -0400: > On Fri, Jun 28, 2013 at 1:59 AM, Daniel Shahaf <danie...@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 <danie...@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
