'svn cp' disregards svn:needs-lock on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

'svn cp' disregards svn:needs-lock on Windows

Anton Shepelev
Hello, all

Is  it  an  error  or  expected  behavior that local
'svn cp' on Windows does not  assign  the  read-only
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 locations?

--
Please, do not forward replies to my e-mail.

Reply | Threaded
Open this post in threaded view
|

Re: 'svn cp' disregards svn:needs-lock on Windows

Branko Čibej
On 24.12.2017 14:27, Anton Shepelev wrote:
> Hello, all
>
> Is  it  an  error  or  expected  behavior that local
> 'svn cp' on Windows does not  assign  the  read-only
> 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 locations?

It's expected. The new file is essentially in a 'modified' state, even
though it's contents have not changed. After you commit it, it will
become read-only in the working copy.

-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: 'svn cp' disregards svn:needs-lock on Windows

Anton Shepelev
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?

> 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.

--
Please, do not forward replies to my e-mail.

Reply | Threaded
Open this post in threaded view
|

Re: 'svn cp' disregards svn:needs-lock on Windows

Branko Čibej
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