You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2011/10/11 12:19:59 UTC
[RFC] Add a 'symlink' node kind in svn_node_kind_t or svn_kind_t
Is it time to create a node-kind enumeration type that includes
'symlink' and use it widely, making symlinks a top-level node kind, at
least on the client side? We have already done this in the WC with
svn_wc__db_kind_t. It seems like we're moving in that direction.
Greg prompted me half way down this email:
<http://svn.haxx.se/dev/archive-2011-10/0084.shtml>, so I knocked up an
initial implementation in the 'tree-read-api' branch:
<http://svn.apache.org/viewvc?revision=1180839&view=revision>,
<http://svn.apache.org/viewvc?revision=1180932&view=revision>.
This introduces 'svn_kind_t' which is like 'svn_node_kind_t' but also
has a 'symlink' kind.
I haven't thought through how this would affect the future of the
'svn:special' property. Were there any plans to make 'svn:special'
describe special files other than symlinks (devices, pipes, etc.)?
Thoughts?
My current attempt at an implementation for svn_ra_check_path2()
<http://svn.apache.org/viewvc?revision=1181040&view=revision> is ugly,
as Bert pointed out in
<http://svn.haxx.se/dev/archive-2011-10/0105.shtml>: it reads the kind
through the RA session, then it reads the properties as a second
operation, and looks for a svn:special property. We'll want a better
solution there and I'm not sure what that would look like.
- Julian
Re: [RFC] Add a 'symlink' node kind in svn_node_kind_t or svn_kind_t
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Oct 11, 2011 at 07:55, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> On Tuesday, October 11, 2011 7:47 AM, "Greg Stein" <gs...@gmail.com> wrote:
>> On Tue, Oct 11, 2011 at 07:21, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> > Greg Stein wrote on Tue, Oct 11, 2011 at 07:03:39 -0400:
>> >...
>> >> Look at it this way: we should have a symlink kind (in svn_kind_t) as
>> >> a first-order value, and then we separately worry about how to marshal
>> >> that kind around and/or represent it within our
>> >> classic/backwards-compat system (read: svn:special). Our current
>> >> interfaces should be talking about symlinks. Under the covers, we do
>> >> "funny stuff" for that kind of node.
>> >
>> > So, taking your line of thought further, in 2.0 svn:special could become
>> > as much of an implementation detail as the "repository-normal form" detail
>> > of svn:eol-style?
>>
>> I think that I was just eaten by a grue.
>>
>> Not sure what you mean here. Twisty passages, and all that.
>>
>
> :)
>
> Consider the following design:
>
> * svn:special is not a user-visible property. (like wcprops/entryprops)
>
> * FS/RA/WC interfaces use enum kind_t { none, dir, file, symlink, unknown }.
>
> * symlinks are marshalled across the wire as plain files with svn:special set.
> (and I'll not open the can of worms of the concrete property name/value that should be used)
>
> I'm asking if that sounds like a logical extension of this RFC. (I'm not saying I particularly like or dislike it; I'm merely putting it on the table.)
Ah. Yes. That is the eventual/logical intent.
We (nominally) have symlinks as first-order concept at the wc_db.*
level, with the intent that wc_db would never see svn:special. But
with all the work just to get wc-ng done, we never got to that point.
So the symlink stuff in wc_db is idle right now. But the hope would be
to properly marshal symlinks, and only surface them as svn:special at
the public API level. Over time, you could see the entire client
operating with svn_kind_symlink, and only the RA layer translates
to/from svn:special.
So yeah... where svn:eol-style is entirely client-side, you could see
the same for svn:special / symlinks. But over time, the symlink could
migrate all the way into the FS.
Cheers,
-g
Re: [RFC] Add a 'symlink' node kind in svn_node_kind_t or svn_kind_t
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Tuesday, October 11, 2011 7:47 AM, "Greg Stein" <gs...@gmail.com> wrote:
> On Tue, Oct 11, 2011 at 07:21, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Greg Stein wrote on Tue, Oct 11, 2011 at 07:03:39 -0400:
> >...
> >> Look at it this way: we should have a symlink kind (in svn_kind_t) as
> >> a first-order value, and then we separately worry about how to marshal
> >> that kind around and/or represent it within our
> >> classic/backwards-compat system (read: svn:special). Our current
> >> interfaces should be talking about symlinks. Under the covers, we do
> >> "funny stuff" for that kind of node.
> >
> > So, taking your line of thought further, in 2.0 svn:special could become
> > as much of an implementation detail as the "repository-normal form" detail
> > of svn:eol-style?
>
> I think that I was just eaten by a grue.
>
> Not sure what you mean here. Twisty passages, and all that.
>
:)
Consider the following design:
* svn:special is not a user-visible property. (like wcprops/entryprops)
* FS/RA/WC interfaces use enum kind_t { none, dir, file, symlink, unknown }.
* symlinks are marshalled across the wire as plain files with svn:special set.
(and I'll not open the can of worms of the concrete property name/value that should be used)
I'm asking if that sounds like a logical extension of this RFC. (I'm not saying I particularly like or dislike it; I'm merely putting it on the table.)
> Cheers,
> -g
>
Re: [RFC] Add a 'symlink' node kind in svn_node_kind_t or svn_kind_t
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Oct 11, 2011 at 07:21, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Greg Stein wrote on Tue, Oct 11, 2011 at 07:03:39 -0400:
>...
>> Look at it this way: we should have a symlink kind (in svn_kind_t) as
>> a first-order value, and then we separately worry about how to marshal
>> that kind around and/or represent it within our
>> classic/backwards-compat system (read: svn:special). Our current
>> interfaces should be talking about symlinks. Under the covers, we do
>> "funny stuff" for that kind of node.
>
> So, taking your line of thought further, in 2.0 svn:special could become
> as much of an implementation detail as the "repository-normal form" detail
> of svn:eol-style?
I think that I was just eaten by a grue.
Not sure what you mean here. Twisty passages, and all that.
Cheers,
-g
Re: [RFC] Add a 'symlink' node kind in svn_node_kind_t or
svn_kind_t
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Tue, Oct 11, 2011 at 07:03:39 -0400:
> On Tue, Oct 11, 2011 at 06:19, Julian Foad <ju...@wandisco.com> wrote:
> >...
> > I haven't thought through how this would affect the future of the
> > 'svn:special' property. Were there any plans to make 'svn:special'
> > describe special files other than symlinks (devices, pipes, etc.)?
>
> Somebody may have thought about that in the past, and they should be
> tarred and feathered. svn:special is an awful hack :-(
>
> Look at it this way: we should have a symlink kind (in svn_kind_t) as
> a first-order value, and then we separately worry about how to marshal
> that kind around and/or represent it within our
> classic/backwards-compat system (read: svn:special). Our current
> interfaces should be talking about symlinks. Under the covers, we do
> "funny stuff" for that kind of node.
>
So, taking your line of thought further, in 2.0 svn:special could become
as much of an implementation detail as the "repository-normal form" detail
of svn:eol-style?
> >...
>
> Cheers,
> -g
Re: [RFC] Add a 'symlink' node kind in svn_node_kind_t or svn_kind_t
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Oct 11, 2011 at 06:19, Julian Foad <ju...@wandisco.com> wrote:
>...
> I haven't thought through how this would affect the future of the
> 'svn:special' property. Were there any plans to make 'svn:special'
> describe special files other than symlinks (devices, pipes, etc.)?
Somebody may have thought about that in the past, and they should be
tarred and feathered. svn:special is an awful hack :-(
Look at it this way: we should have a symlink kind (in svn_kind_t) as
a first-order value, and then we separately worry about how to marshal
that kind around and/or represent it within our
classic/backwards-compat system (read: svn:special). Our current
interfaces should be talking about symlinks. Under the covers, we do
"funny stuff" for that kind of node.
>...
Cheers,
-g