>Tom argued that the information should be retrieved with update, but
>update isn't related to locking: it may even be undesirable to run
>update in the middle of the preparation of a commit, yet it may be
>desirable to take out a lock. He also said "file X was locked since
>the working copy got updated": there's no way to tell when a file got
>locked (before or after update) because locks aren't attached to a
>specific revision but to a path in the repository.
>
>Does that explain it?
Actually I argued that getting the information on an update is one way
to get it. By no means did I mean to imply it should be the only way.
As for the "No way to tell", I already responded on how to do that.
I do an update, File A is locked. The working copy flags it. Now
obviously it was locked before I updated because I found it when I
updated. User B unlocks the file, I do another update. The update code
(obviously modified) notes my working copy's lock flag and checks the
lock status on the file. Oh look, no lock anymore. Lock existed in
working copy before update, lock no longer found, therefore lock was
released before update. Simple logic.
Reverse case. Before I do an update, file is not locked, so no flag is
set in my working copy. The update code looks in the repository and
sees that the file is locked. (Again OBVIOUSLY this requires a code
mode to look for locks) A compare against the working copy flag on the
file notes that the file was NOT flagged as locked in my working copy,
but is locked in the repository, therefore the lock occurred before my
update. Again, blindingly simple logic, it's a binary solution, no need
for timestamps or any other complex checks.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 14 21:06:43 2007