On Mon, Jul 1, 2013 at 8:48 AM, Daniel Shahaf <danielsh_at_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 <danielsh_at_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
Received on 2013-07-01 23:34:42 CEST