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" <gst...@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