subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@red-bean.com>
Subject Re: BUG: Delete svn:special property on symlink; hilarity ensues.
Date Tue, 04 Sep 2018 16:51:30 GMT
Daniel Shahaf <d.s@daniel.shahaf.name> writes:
>However, in higher layers, that do know of svn:special's semantics, I
>don't know if it makes sense to allow a node to change type from "file"
>to "symlink".  Note that we added svn_node_symlink to svn_node_kind_t
>(inĀ 1.8) as a distinct value; the thinking then, IIRC, was to move
>towards symlinks as first-class citizens.

I think you're right, and this matches well with what Brane said in this thread too:

>The only correct way to change a node's type is to replace the node itself.

So, on to your proposal:

>That proposal is certainly simple and predictable.  However, I'd like to
>spell out an alternative proposal, driven by "nodes shouldn't change
>types" thinking:
>
>1. Retain the ability to add special files by writing their
>repository-normal contents to a file and doing 'svn add foo; svn ps
>svn:special yes foo'.
>
>2. Have 'svn propdel svn:special' error out with "use 'svn rm' instead".
>
>3. Disallow changing the svn:special type of a file (such as from "link"
>to something else).

I like that better than my proposal.

>Rationale (#1): This is the canonical way to add symlinks on windows.  This
>is also the canonical forward-compatible way to add, using a 1.10
>client, any svn:special types (besides SVN_SUBST__SPECIAL_LINK_STR) we
>might invent in 1.11.
>
>Rationale (#2 and #3): nodes shouldn't change types.  In #2 and #3 we
>might want to have a --force-changing-svn:special-type escape hatch,
>allowing the error to be overruled, for forward compatibility.
>
>The case of 'svn propset svn:special yes' of a file that isn't a
>locally-added-without-history one would behave similarly.
>
>I'm not sure yet which proposal I'd back, by the way.  The above is just
>out-loud thinking.

I agree with all of this.  As far as I'm concerned, this would be a fine behavior.  In the
specific usage circumstances I was in, this behavior would have nudged me to do The Right
Thing (namely, 'svn rm' and replace the node).

Basically, we're making "svn:special" be a property that users can't manipulate directly when
the proper special behaviors are available on on the system.  IOW, if your system supports
symlinks, then the user shouldn't try to do things to the "svn:special" property, but should
instead do things to symlinks.

If the system doesn't support symlinks, then we fall back to allowing the user to do things
to Subversion's underlying representation, because that's pretty much the only thing we can
offer that allows the user to collaborate with users on symlink-supporting systems.

Best regards,
-Karl

Mime
View raw message