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@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!

Reply via email to