Re: BUG: Delete svn:special property on symlink; hilarity ensues.

Daniel Shahaf <d.s_at_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
Received on 2018-09-04 18:51:43 CEST