You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2013/06/27 21:16:02 UTC
Ev2 symlinks
On IRC, Branko noted:
on the subject of ev2 api, i'm wondering if add_symlink and
alter_symlink should really be there. it looks like special-casing on
one type of special node
There is *only* one type of special node. There are no plans for any
other type of special node. The current design of a pseudo-file is
ridiculous. wc_db and Ev2 break out the three node types that we deal
with: dir, file, symlink. As part of that symlink was added to
svn_node_kind_t, so that we can talk about symlinks as first-class
items.
The svn:special design is horrible. For backwards compat and wire
protocol purposes, we'll always have to deal with it, but we can fix
our top-level APIs.
Cheers,
-g
Re: Ev2 symlinks
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <da...@elego.de> writes:
> (pop quiz: who ran 'make check' with 1.7 client and 1.8 server, or 1.8
> client and 1.7 server, during the soak?).
I did it shortly before the soak, I raised issue 4348 :)
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
Re: Ev2 symlinks
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Jul 1, 2013 at 8:48 AM, Daniel Shahaf <da...@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 <da...@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
Re: Ev2 symlinks
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Fri, Jun 28, 2013 at 02:49:01 -0400:
> On Fri, Jun 28, 2013 at 1:59 AM, Daniel Shahaf <da...@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 <da...@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
Re: Ev2 symlinks
Posted by Branko Čibej <br...@wandisco.com>.
On 28.06.2013 07:19, Daniel Shahaf wrote:
> So, to be explicit: calling add_symlink() when driving the FS commit
> editor is a bug; calling add_file(svn:special='*', contents="link foo")
> when driving the wc-ng update editor is also a bug.
>
> I suppose we could have a wrapper editor that converts from one form to
> the other, or validates that the "wrong" way to add a symlink isn't
> used. If we code the assertions tightly enough [1], we might even be
> able to avoid bugs.
In the end it's all a matter of negotiating capabilities and selecting
the correct wrapper editor for the peer. I suspect it's even RA-layer
independent.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Ev2 symlinks
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jun 28, 2013 at 1:59 AM, Daniel Shahaf <da...@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 <da...@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
future).
Cheers,
-g
Re: Ev2 symlinks
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Fri, Jun 28, 2013 at 01:25:42 -0400:
> On Fri, Jun 28, 2013 at 1:19 AM, Daniel Shahaf <da...@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()?
You want to allow written-against-1.9 clients to call add_file() that
way, but you just said below that that add_file() call is forbidden to
written-against-1.10 clients. How do these requirements coexist?
> > calling add_file(svn:special='*', contents="link foo")
> > when driving the wc-ng update editor is also a bug.
>
> Correct. If you're driving Ev2, then you should not be working with
> "special" files. You should be working with the appropriate node_kind
> values.
>
> The "old" "special" representation is just that: old. In wc-ng and
> Ev2, you work directly with symlinks.
>
> >...
>
> Cheers,
> -g
Re: Ev2 symlinks
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jun 28, 2013 at 1:19 AM, Daniel Shahaf <da...@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)
> calling add_file(svn:special='*', contents="link foo")
> when driving the wc-ng update editor is also a bug.
Correct. If you're driving Ev2, then you should not be working with
"special" files. You should be working with the appropriate node_kind
values.
The "old" "special" representation is just that: old. In wc-ng and
Ev2, you work directly with symlinks.
>...
Cheers,
-g
Re: Ev2 symlinks
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Fri, Jun 28, 2013 at 01:04:26 -0400:
> On Fri, Jun 28, 2013 at 12:52 AM, Daniel Shahaf <da...@apache.org> wrote:
> >...
> > In second thought, this just moves the problem: the wc layer would want to call
> > add_symlink() during a commit.
> >
> > But I'd like to avoid the ambiguity still: either add_symlink() or
> > add_file(svn:special=yes), not both; either add_blockdev() or add_special(),
> > not both. Not sure how we can avoid this...
>
> My decision in Ev2 was to surface the direct types, and work with them
> as long as possible (*). When you hit a compatibility barrier, then
> you transform.
>
> Something I learned a long while ago from Guido was to avoid:
>
> foo(arg=False)
> foo(arg=True)
>
> def foo(arg):
> if arg:
> one_thing()
> else:
> other_thing()
>
> The argument shouldn't exist. Just have fooFalse() and fooTrue().
>
> In that vein, wc_db and Ev2 avoid the add(kind=KIND) form, as the args
> and underlying work are different for each KIND. The arguments are:
> <props,content,checksum> vs <props,children> vs <props,target>. (and
> don't forget add_absent!)
>
> I would continue to push a per-kind API, which collapses to
> svn:special when it hits the FS. Or one day the FS will directly
> handle the various node kinds. Or svn:special over http/svn, with the
> collapse within RA. Or ...
>
So, to be explicit: calling add_symlink() when driving the FS commit
editor is a bug; calling add_file(svn:special='*', contents="link foo")
when driving the wc-ng update editor is also a bug.
I suppose we could have a wrapper editor that converts from one form to
the other, or validates that the "wrong" way to add a symlink isn't
used. If we code the assertions tightly enough [1], we might even be
able to avoid bugs.
Cheers,
Daniel
[1] which is made easier by the fact that alter_file() takes a contents
stream rather than a delta stream: we can cheaply check for
contents.startswith("link ").
> Cheers,
> -g
>
> (*) kinda like we're doing with moves, fwiw
Re: Ev2 symlinks
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jun 28, 2013 at 12:52 AM, Daniel Shahaf <da...@apache.org> wrote:
>...
> In second thought, this just moves the problem: the wc layer would want to call
> add_symlink() during a commit.
>
> But I'd like to avoid the ambiguity still: either add_symlink() or
> add_file(svn:special=yes), not both; either add_blockdev() or add_special(),
> not both. Not sure how we can avoid this...
My decision in Ev2 was to surface the direct types, and work with them
as long as possible (*). When you hit a compatibility barrier, then
you transform.
Something I learned a long while ago from Guido was to avoid:
foo(arg=False)
foo(arg=True)
def foo(arg):
if arg:
one_thing()
else:
other_thing()
The argument shouldn't exist. Just have fooFalse() and fooTrue().
In that vein, wc_db and Ev2 avoid the add(kind=KIND) form, as the args
and underlying work are different for each KIND. The arguments are:
<props,content,checksum> vs <props,children> vs <props,target>. (and
don't forget add_absent!)
I would continue to push a per-kind API, which collapses to
svn:special when it hits the FS. Or one day the FS will directly
handle the various node kinds. Or svn:special over http/svn, with the
collapse within RA. Or ...
Cheers,
-g
(*) kinda like we're doing with moves, fwiw
Re: Ev2 symlinks
Posted by Daniel Shahaf <da...@apache.org>.
On Fri, Jun 28, 2013 at 07:20:34AM +0300, Daniel Shahaf wrote:
> Greg Stein wrote on Thu, Jun 27, 2013 at 22:25:48 -0400:
> > On Thu, Jun 27, 2013 at 8:40 PM, Daniel Shahaf <da...@elego.de> wrote:
> > > Greg Stein wrote on Thu, Jun 27, 2013 at 20:33:39 -0400:
> > >> On Thu, Jun 27, 2013 at 8:01 PM, Daniel Shahaf <da...@elego.de> wrote:
> > >> > Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
> > >> >> On 27.06.2013 21:16, Greg Stein wrote:
> > >> >> > On IRC, Branko noted:
> > >> >> > on the subject of ev2 api, i'm wondering if add_symlink and
> > >> >> > alter_symlink should really be there. it looks like special-casing on
> > >> >> > one type of special node
> > >> >> >
> > >> >> >
> > >> >> > There is *only* one type of special node. There are no plans for any
> > >> >> > other type of special node.
> > >> >>
> > >> >> Yes, there are. And not only in my head, either. :)
> > >> >> I just haven't got around to starting a design doc.
> > >> >>
> > >> >
> > >> > And the question is: once someone invents a kind of svn:special node
> > >> > (besides "link"), how would Ev2 represent it?
> > >>
> > >> Add more APIs to Ev2. Since it is not a vtable-based API, extension is
> > >> very easy.
> > >
> > > So if Ev2 is released in 1.9 and we invent a new svn:special kind in
> > > 1.10, you need to have a 1.10 client *and* server in order to use it.
> >
> > That doesn't follow. There is a difference between APIs and
> > serialization. We can surface new types in the API, and serialize in
> > backwards-compatible ways. A 1.10 client can talk about (say) block
> > devices all over the place, but serialize it over the wire as
> > svn:special to a 1.9 server.
> >
> > wc-1.0's model of "is this file special?" was a horrible model.
> > WC-NG/wc_db/Ev2 fix that. They surface the type explicitly.
> >
> > But it can all be serialized via svn:special if you want. Until the FS
> > changes, there is no need to change the wire serialization. But it
> > *is* (and *has been*) very helpful to change the coding model.
>
> Is it? Suppose 1.10 adds block devices. The 1.10 libsvn_wc will need
> to implement handling of block devices in two places: in add_blockdev()
> for use with 1.10 servers, and in add_file()-conditioned-upon-svn:special
> for use with 1.9 servers. That creates ambiguity. It's also a kind of
> bug that we are liable miss (pop quiz: who ran 'make check' with
> 1.7 client and 1.8 server, or 1.8 client and 1.7 server, during the
> soak?).
>
> How about removing svn_editor_add_symlink() but retaining
> svn_editor_cb_add_symlink_t()? The libsvn_delta/editor.c code can
In second thought, this just moves the problem: the wc layer would want to call
add_symlink() during a commit.
But I'd like to avoid the ambiguity still: either add_symlink() or
add_file(svn:special=yes), not both; either add_blockdev() or add_special(),
not both. Not sure how we can avoid this...
> arrange to dispatch to the add_symlink() callback if it has been
> provided and to add_file() otherwise. That way the amibiguity on the
> driver's side is removed, and the consumer's code is clean too (it has
> a separate add_symlink() entry point).
>
> Daniel
Re: Ev2 symlinks
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Thu, Jun 27, 2013 at 22:25:48 -0400:
> On Thu, Jun 27, 2013 at 8:40 PM, Daniel Shahaf <da...@elego.de> wrote:
> > Greg Stein wrote on Thu, Jun 27, 2013 at 20:33:39 -0400:
> >> On Thu, Jun 27, 2013 at 8:01 PM, Daniel Shahaf <da...@elego.de> wrote:
> >> > Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
> >> >> On 27.06.2013 21:16, Greg Stein wrote:
> >> >> > On IRC, Branko noted:
> >> >> > on the subject of ev2 api, i'm wondering if add_symlink and
> >> >> > alter_symlink should really be there. it looks like special-casing on
> >> >> > one type of special node
> >> >> >
> >> >> >
> >> >> > There is *only* one type of special node. There are no plans for any
> >> >> > other type of special node.
> >> >>
> >> >> Yes, there are. And not only in my head, either. :)
> >> >> I just haven't got around to starting a design doc.
> >> >>
> >> >
> >> > And the question is: once someone invents a kind of svn:special node
> >> > (besides "link"), how would Ev2 represent it?
> >>
> >> Add more APIs to Ev2. Since it is not a vtable-based API, extension is
> >> very easy.
> >
> > So if Ev2 is released in 1.9 and we invent a new svn:special kind in
> > 1.10, you need to have a 1.10 client *and* server in order to use it.
>
> That doesn't follow. There is a difference between APIs and
> serialization. We can surface new types in the API, and serialize in
> backwards-compatible ways. A 1.10 client can talk about (say) block
> devices all over the place, but serialize it over the wire as
> svn:special to a 1.9 server.
>
> wc-1.0's model of "is this file special?" was a horrible model.
> WC-NG/wc_db/Ev2 fix that. They surface the type explicitly.
>
> But it can all be serialized via svn:special if you want. Until the FS
> changes, there is no need to change the wire serialization. But it
> *is* (and *has been*) very helpful to change the coding model.
Is it? Suppose 1.10 adds block devices. The 1.10 libsvn_wc will need
to implement handling of block devices in two places: in add_blockdev()
for use with 1.10 servers, and in add_file()-conditioned-upon-svn:special
for use with 1.9 servers. That creates ambiguity. It's also a kind of
bug that we are liable miss (pop quiz: who ran 'make check' with
1.7 client and 1.8 server, or 1.8 client and 1.7 server, during the
soak?).
How about removing svn_editor_add_symlink() but retaining
svn_editor_cb_add_symlink_t()? The libsvn_delta/editor.c code can
arrange to dispatch to the add_symlink() callback if it has been
provided and to add_file() otherwise. That way the amibiguity on the
driver's side is removed, and the consumer's code is clean too (it has
a separate add_symlink() entry point).
Daniel
Re: Ev2 symlinks
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 27, 2013 at 8:40 PM, Daniel Shahaf <da...@elego.de> wrote:
> Greg Stein wrote on Thu, Jun 27, 2013 at 20:33:39 -0400:
>> On Thu, Jun 27, 2013 at 8:01 PM, Daniel Shahaf <da...@elego.de> wrote:
>> > Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
>> >> On 27.06.2013 21:16, Greg Stein wrote:
>> >> > On IRC, Branko noted:
>> >> > on the subject of ev2 api, i'm wondering if add_symlink and
>> >> > alter_symlink should really be there. it looks like special-casing on
>> >> > one type of special node
>> >> >
>> >> >
>> >> > There is *only* one type of special node. There are no plans for any
>> >> > other type of special node.
>> >>
>> >> Yes, there are. And not only in my head, either. :)
>> >> I just haven't got around to starting a design doc.
>> >>
>> >
>> > And the question is: once someone invents a kind of svn:special node
>> > (besides "link"), how would Ev2 represent it?
>>
>> Add more APIs to Ev2. Since it is not a vtable-based API, extension is
>> very easy.
>
> So if Ev2 is released in 1.9 and we invent a new svn:special kind in
> 1.10, you need to have a 1.10 client *and* server in order to use it.
That doesn't follow. There is a difference between APIs and
serialization. We can surface new types in the API, and serialize in
backwards-compatible ways. A 1.10 client can talk about (say) block
devices all over the place, but serialize it over the wire as
svn:special to a 1.9 server.
wc-1.0's model of "is this file special?" was a horrible model.
WC-NG/wc_db/Ev2 fix that. They surface the type explicitly.
But it can all be serialized via svn:special if you want. Until the FS
changes, there is no need to change the wire serialization. But it
*is* (and *has been*) very helpful to change the coding model.
> That's a #lose, sorry. The way svn:special works now means even 1.0
> clients and servers can talk about any svn:special kind we might add
> whenever. I see no compelling reason to break that functionality.
You're mixing API expression and serialization.
Cheers,
-g
Re: Ev2 symlinks
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Thu, Jun 27, 2013 at 20:33:39 -0400:
> On Thu, Jun 27, 2013 at 8:01 PM, Daniel Shahaf <da...@elego.de> wrote:
> > Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
> >> On 27.06.2013 21:16, Greg Stein wrote:
> >> > On IRC, Branko noted:
> >> > on the subject of ev2 api, i'm wondering if add_symlink and
> >> > alter_symlink should really be there. it looks like special-casing on
> >> > one type of special node
> >> >
> >> >
> >> > There is *only* one type of special node. There are no plans for any
> >> > other type of special node.
> >>
> >> Yes, there are. And not only in my head, either. :)
> >> I just haven't got around to starting a design doc.
> >>
> >
> > And the question is: once someone invents a kind of svn:special node
> > (besides "link"), how would Ev2 represent it?
>
> Add more APIs to Ev2. Since it is not a vtable-based API, extension is
> very easy.
So if Ev2 is released in 1.9 and we invent a new svn:special kind in
1.10, you need to have a 1.10 client *and* server in order to use it.
That's a #lose, sorry. The way svn:special works now means even 1.0
clients and servers can talk about any svn:special kind we might add
whenever. I see no compelling reason to break that functionality.
Re: Ev2 symlinks
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 27, 2013 at 8:01 PM, Daniel Shahaf <da...@elego.de> wrote:
> Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
>> On 27.06.2013 21:16, Greg Stein wrote:
>> > On IRC, Branko noted:
>> > on the subject of ev2 api, i'm wondering if add_symlink and
>> > alter_symlink should really be there. it looks like special-casing on
>> > one type of special node
>> >
>> >
>> > There is *only* one type of special node. There are no plans for any
>> > other type of special node.
>>
>> Yes, there are. And not only in my head, either. :)
>> I just haven't got around to starting a design doc.
>>
>
> And the question is: once someone invents a kind of svn:special node
> (besides "link"), how would Ev2 represent it?
Add more APIs to Ev2. Since it is not a vtable-based API, extension is
very easy.
Cheers,
-g
Re: Ev2 symlinks
Posted by Daniel Shahaf <da...@elego.de>.
Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
> On 27.06.2013 21:16, Greg Stein wrote:
> > On IRC, Branko noted:
> > on the subject of ev2 api, i'm wondering if add_symlink and
> > alter_symlink should really be there. it looks like special-casing on
> > one type of special node
> >
> >
> > There is *only* one type of special node. There are no plans for any
> > other type of special node.
>
> Yes, there are. And not only in my head, either. :)
> I just haven't got around to starting a design doc.
>
And the question is: once someone invents a kind of svn:special node
(besides "link"), how would Ev2 represent it?
Daniel
> > The current design of a pseudo-file is ridiculous.
>
> I agree that better designs are possible. Certainly the pseudo-file
> approach should be an implementation detail of the wire protocol.
> However, I would hesitate to invent actual new node types because they
> cannot be represented in older repositories, making the client<->server
> compatibility problem harder.
>
> > wc_db and Ev2 break out the three node types that we deal
> > with: dir, file, symlink. As part of that symlink was added to
> > svn_node_kind_t, so that we can talk about symlinks as first-class
> > items.
>
> Later in that same IRC log I concluded that talking about symlinks to
> the WC makes sense, as they're something most filesystems know about.
>
> > The svn:special design is horrible. For backwards compat and wire
> > protocol purposes, we'll always have to deal with it, but we can fix
> > our top-level APIs.
>
> That depends on what you call a top-level API; mine for symlinks is
> called "ln" :)
>
> -- Brane
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane@wandisco.com
Re: Ev2 symlinks
Posted by Branko Čibej <br...@wandisco.com>.
On 27.06.2013 21:16, Greg Stein wrote:
> On IRC, Branko noted:
> on the subject of ev2 api, i'm wondering if add_symlink and
> alter_symlink should really be there. it looks like special-casing on
> one type of special node
>
>
> There is *only* one type of special node. There are no plans for any
> other type of special node.
Yes, there are. And not only in my head, either. :)
I just haven't got around to starting a design doc.
> The current design of a pseudo-file is ridiculous.
I agree that better designs are possible. Certainly the pseudo-file
approach should be an implementation detail of the wire protocol.
However, I would hesitate to invent actual new node types because they
cannot be represented in older repositories, making the client<->server
compatibility problem harder.
> wc_db and Ev2 break out the three node types that we deal
> with: dir, file, symlink. As part of that symlink was added to
> svn_node_kind_t, so that we can talk about symlinks as first-class
> items.
Later in that same IRC log I concluded that talking about symlinks to
the WC makes sense, as they're something most filesystems know about.
> The svn:special design is horrible. For backwards compat and wire
> protocol purposes, we'll always have to deal with it, but we can fix
> our top-level APIs.
That depends on what you call a top-level API; mine for symlinks is
called "ln" :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com