I've been testing the lock features of 1.2 today, and cannot understand
the behavior of svn with stolen locks.
Scenario:
1. Choose any file "foo" in a repo (1.2).
2. Checkout that file into two distinct working copies (two separate
directory locations). Call these directories "L1" and "L2". Each will
now have "foo".
svn co svn://server/repo/foo L1
svn co svn://server/repo/foo L2
3. Lock the foo in L1 and check the status in L1 and L2 with the -u
switch to show "K" in L1 and "O" in L2. This is expected behavior (at
least, by me).
svn lock L1/foo
svn status -u L1/foo
svn status -u L2/foo
4. Now steal the lock into L2 and check the status again. This now shows
"K" in L2 and "T" in L1. Again, this is expected behavior.
svn lock L2/foo --force
svn status -u L1/foo
svn status -u L2/foo
5. Now modify "foo" in L2 (where it is locked), and check it in.
ls >>L2/foo
svn ci L2/foo
6. Check the status on both copies again. Oddly, it's unchanged: "K" in
L2 and "T" in L1. I did *not* expect this; I *thought* the commit was
supposed to remove the lock, but somehow the stolen status in L1 seems
to have blocked this behavior. Is this by design?
7. OK, now manually remove the residual lock on L2, then check status again.
svn unlock L2/foo
svn status -u L1/foo
svn status -u L2/foo
OK, this one I cannot work out at all. At this point the L2 foo
correctly shows nothing (unlocked), but now L1 has reverted to "K"
(locked). Huh? I *was* expecting this to maybe go to "B" (broken), but
the "K" has me totally confused. It's almost like stealing the lock was
really a borrow operation, with the old lock status pushed onto some
hidden server-based stack.
Can anyone throw some light on this? Is this expected behavior? I can't
find any mentions in the early locking docs at all.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 9 02:11:15 2005