Running update on the working copy after that commit will automatically remove the lock from the working copy. (An update between the stealing of the lock and the delete would do the same thing).
When a node is deleted from the working copy during update or switch your client can't be sure why that happened (you might have updated to a revision I'm which that file doesn't exist).
Just removing the lock token from a wc when it might still be valid is a bigger issue, than not noticing that a lock is stolen. Stealing a lock was never intended to be a common operation as it breaks the entire idea of using locks.
Bert
From: Zi Wang
Sent: Friday, March 14, 2014 8:49 PM
To: users_at_subversion.apache.org
Hello, please help me to understand this:
Here is the scenario:
Two person A and B are working on the same project and both have a working copy on their machine,
A: Lock(check out) a file, call it FILE_X
B: Break FILE_X's lock, then Delete FILE_X and Commit
A: Update (now FILE_X is gone on A's working copy), then Add a new file also called FILE_X, then Commit
Now, at this point, FILE_X on A's working copy will have a Lock, even though it was a new file just with the same name, how come? Does SVN remembers the status? If so, is there a way to tell SVN to 'forgot' the status?
Thank you!
Received on 2014-03-15 08:08:38 CET