[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Ev2 symlinks

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 28 Jun 2013 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". ??

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).

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.

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-06-28 08:49:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.