[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 8 Nov 2012 09:09:46 +0200

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.
Received on 2012-11-08 08:10:24 CET

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