subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: 'svn cp' disregards svn:needs-lock on Windows
Date Sun, 24 Dec 2017 19:50:27 GMT
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


Mime
View raw message