On 24.12.2017 20:41, Anton Shepelev wrote:
> Brane to Anton Shepelev:
>
>>> Is it an error or expected behavior that local
>>> attribute to the copies of files that have the
>>> svn:needs-lock property and are marked as read-
>>> only in the woking copy at their original loca-
>>> tions?
>> It's expected. The new file is essentially in a
>> 'modified' state, even though it's contents have
>> not changed.
> Does not this violate the requirement to lock a file
> *prior* to modifying it?
No. The file does not exist in the repository, it exists only in your
working copy, which means that no-one else can modify it. File locks are
a way to tell other users that a file is being modified, and that makes
no sense for files that do not even exist for other users yet.
>> After you commit it, it will become read-only in
>> the working copy.
> No, it does not. Only after I delete the file and
> update it, does SVN "restore" it with the read-only
> attribute.
That might be a bug on Windows or it might be a bug in your version of
the Subversion client. I've tested this scenario with 1.9.7 on Unix and
the file definitely becomes read-only after the commit.
-- Brane
Received on 2017-12-24 20:50:35 CET