On Mon, Jul 1, 2013 at 8:48 AM, Daniel Shahaf <danie...@elego.de> wrote: > 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: >... >> > 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.
You said "a 1.9 app". What you're saying above is that a *user* of a 1.9 app will create a file that causes the stated function call. In your example, the 1.9 app wouldn't ever call add_blockdev() since it doesn't exist. When you serialize it over the wire (as file+svn:special), the server would deserialize it as a call to add_blockdev(). I think the more interesting question is what does libsvn_fs-1.10 when a 1.9 app makes that add_file() call(*). I might have some editing app that directly uses the FS API. And that app doesn't know to make the translation. But the answer here is *very* easy! The change is within editor.c. If you call svn_editor_add_file(special/blockdev), then *internally* it transforms that to a call to funcs.cb_add_blockdev(). (*) I don't know why a 1.9 app would think to include blockdev; presumably, the app is getting that from the user, who "knows" our round-trip serialization story. But the user must be careful: 1.10 might store blockdevs in wc.db on Windows, and never touch the disk. They could be as ephemeral as properties. > 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's easier to talk about if you remove the wire (de)serialization step. But we do have an answer, once we define a round-trip mechanism for older clients. It could be an empty file with a single property: svn:blockdev=#.# (rather than piling onto svn:special). >... Cheers, -g
