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
