Karl Fogel <kfogel@red-bean.com> writes:
> Philip Martin <philip@codematters.co.uk> writes:
>>
>> I think that setting svn:executable on a symbolic link should have no
>> effect, perhaps even be an error, irrespective of whether the symbolic
>> link points at a file or directory. I think it is wrong for the
>> client to change the permission of a target outside the working copy,
>> if that is where the symbolic link points, and if it points inside the
>> working copy then we can require the user to set permissions on the
>> target not the link.
>
> Do you mean that setting the property should be a noop-or-error, or
> that the consequent attempt to tweak the x-bit should noop-or-error?
The client should not tweak the x-bit. The client could also
warn/error/ignore attempts to set the property but that's not so
important, and relying on the client enforcing rules about properties
is not good since earlier/other clients won't necessarily do it.
> I prefer the latter way, with no-op, partly because it's easier to
> implement, and partly because it might give saner behavior when a
> file's type changes.
>
> It could be implemented entirely in io_set_file_perms(). You'd be
> allowed to set/unset the property, it just won't have any effect on
> the x-bit on platforms that care about the x-bit, because the calls to
> change the x-bit will have no effect. As for saner behavior,
> consider:
>
> The x-bit behavior would be based on the working type, not the
> versioned type. In other words, in this sequence of commands
>
> $ echo "I'm a regular file." > newfile
> $ svn add newfile
> $ svn commit -m "Add new file."
> $ rm newfile
> $ ln -s oldfile newfile
> $ svn propverb svn:executable newfile
>
> the last command would set the property, but have no effect on the
> x-bit. And in this sequence of commands
>
> $ ln -s oldfile newfile
> $ svn add newfile
> $ svn commit -m "Add new file."
> $ rm newfile
> $ echo "Now I'm a regular file." > newfile
> $ svn propverb svn:executable newfile
At present, attempts to change a file type like generate obstructions
in the working copy, the user needs to manually set/clear svn:special
as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 18 20:30:25 2007