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
