[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Branko ─îibej <brane_at_apache.org>
Date: Sun, 24 Dec 2017 20:50:27 +0100

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

This is an archived mail posted to the Subversion Users mailing list.