On Tuesday, October 11, 2011 7:47 AM, "Greg Stein" <[email protected]> wrote:
> On Tue, Oct 11, 2011 at 07:21, Daniel Shahaf <[email protected]> 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
>
