[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 01 Sep 2018 19:14:20 +0000

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.


(stsp: I've started drafting a reply but haven't finished yet...)
Received on 2018-09-01 21:14:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.