Karl Fogel wrote on Fri, 31 Aug 2018 14:06 -0500: > Daniel Shahaf <d...@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...)
