Karl Fogel wrote on Fri, 31 Aug 2018 14:06 -0500:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> >This is exactly how one adds or edits a symlink on !HAVE_SYMLINK
> >platforms, including Windows. (You can get this behaviour on Unix if
> >you get configure to lie about the HAVE_SYMLINK test result.) I suppose
> >it's a public API therefore, although it's a bit odd that our
> >serialization format _is_ our public API; I'd have expected some sort of
> >layering decoupling the two.
>
> Well, I don't mind the part about our serialization format also being
> effectively our API for this.
>
> But the question is, what *should* the behavior be if one deletes the
> 'svn:special' property of a symlink?
>
> $ svn propdel svn:special some_version_controlled_symlink
> $ svn status -q
> ~M some_version_controlled_symlink
> $ svn commit -m "This commit will fail."
> svn: E145001: Commit failed (details follow):
> svn: E145001: Node '/.../some_version_controlled_symlink has \
> unexpectedly changed kind
> $
>
> The above doesn't seem right...
>
As far as the FS layer is concerned, sure. In that layer, svn:special
is just another property, with no special semantics, behaving exactly as
in your proposal. (No pun intended)
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 my original proposal is a sane outcome, or is maybe the least
> insane outcome. But I'd like to know what others think.
>
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).
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.
Cheers,
Daniel
(stsp: I've started drafting a reply but haven't finished yet...)
Received on 2018-09-01 21:14:36 CEST