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

Re: [RFC] Add a 'symlink' node kind in svn_node_kind_t or svn_kind_t

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 11 Oct 2011 08:50:15 -0400

On Tue, Oct 11, 2011 at 07:55, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> On Tuesday, October 11, 2011 7:47 AM, "Greg Stein" <gstein_at_gmail.com> wrote:
>> On Tue, Oct 11, 2011 at 07:21, Daniel Shahaf <d.s_at_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.

Received on 2011-10-11 14:50:48 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.