Daniel Shahaf wrote on Thu, Nov 08, 2012 at 09:07:07 +0200: > Branko Čibej wrote on Thu, Nov 08, 2012 at 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. > > > > I would agree that being able to add/rm svn:special on a file node _that > already exists in the repository_ is a bug. But being able to do that > on a locally-added file is a feature --- it's what allows Windows users > to create versioned symlinks: > > printf "link bar" > foo && svn add foo && svn ps svn:special yes foo && svn > ci > > If we don't like changing the specialness of a local addition, we could > deprecate (or break) that behaviour and have people run > 'svn add --with-revprop svn:special=yes foo' instead.
BTW, it would be nice if the recipe for creating versioned symlinks on Windows worked on Unixes too. For example, the 'svn add --with-revprop' command could replace 'foo' --- which would be a normal file at that point --- with an actual symlink.
