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

Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py

From: Branko Čibej <brane_at_wandisco.com>
Date: Thu, 08 Nov 2012 06:13:22 +0100

On 08.11.2012 05:26, Daniel Shahaf wrote:
> Branko Čibej wrote on Thu, Nov 08, 2012 at 04:13:52 +0100:
>> I believe that the correct approach would be to always treat a changed
>> node kind (that's either the appearance/disappearance of the svn:symlink
>> property, or a change of the initial keyword in the special-file
>> contents) as if it were a replacement, for the purpose of conflict
>> detection and resolution, even though the node didn't actually get
>> replaced.
> Should we allow nodes to change their special-ness (namely: whether
> they have svn:special set, and if yes what's the initial keyword)
> without a replace?
>
> i.e., sure, current clients can do that --- "svn ps svn:special yes
> COMMITTERS" --- so we'll have to handle that in libsvn_wc. But maybe we
> shouldn't allow any more instances of that.

Good point. It might be a good idea to simply forbid setting or deleting
svn:special explicitly, and also refusing to commit the file if its
contents were modified in a way that changes the special type.

Effectively that means you could only create special files through
indirect means, e.g., by "svn add"ing a symlink.

That wouldn't remove the work needed to fix the tree conflict bug, but
it would make the svn:special semantics clearer. I personally don't
think we have to worry about backward compatibility at that level; I'd
rather treat the fact that you can directly manipulate svn:special as a bug.

-- Brane
Received on 2012-11-08 06:14:02 CET

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