[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: Branko Čibej <brane_at_apache.org>
Date: Sun, 2 Sep 2018 02:35:25 +0200

On 01.09.2018 21:14, Daniel Shahaf wrote:
> 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...

Sure it does. We could forbid deleting the svn:special property in the
command-line client, but that would just be papering over the underlying

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

I admit it could be nice to stop the user from accidentally doing
something that would make the WC uncommittable. We're already safe as
far as the repository is concerned, so, patches welcome to change the
client-side UI.

-- Brane
Received on 2018-09-02 02:35:34 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.