If it's only the server that knows about locks then, unless you change
"svn status" to always query the server, it's better to show users
nothing than to show them something that could be wrong.
Matt.
-----Original Message-----
From: Moore, Tom [mailto:Tom.Moore@aig.com]
Sent: 14 November 2007 15:38
To: Erik Huelsmann
Cc: Andy Levy; users@subversion.tigris.org
Subject: RE: Locking
Your points:
A) Only the server has data that can be constantly considered accurate.
B) The only way to ensure accurate data is to query the server.
C) Placing lock data in the working copy would cause the data in the
working copy to potentially be inaccurate.
D) Placing the svn:needs-lock attribute on a file enforces the need to
request a lock thereby meeting B) and notifying the user if a lock
pre-exists
My response:
E) Given A and B, it follows that the data in the working copy must be
assumed to be inaccurate unless proven accurate by a query to the
server.
F) C is consistent with the expected condition E as derived from A and
B.
G) Subversion by design provides two lock/unlock models. Always enforce
need for lock (D) or un-enforced lock on desire. D only covers locking
model cases where the file needs to always be locked. It does not cover
the case for occasional locking. (I know, my original post discussed
only required locks)
H) The svn update and svn checkout commands are queries to the server
I) Given H the requirement for B is met.
Unless I missed something, this is a logical model that proves that the
addition of this functionality is consistent with your arguments
While I was writing this you made another response on the thread:
> Then they both want to commit. User A notices he should have acquired
> the lock and tries to do so, but the file is locked in the
> repository.... Why didn't his working copy indicate that?! In the
> past he had always had locks indicated to him by his working copy!
> So, Subversion must be broken, right?
Response:
Case E. Data in working copy must be assumed to be out of date. User A
and B both update, then B locks but A forgets to initially lock. If
later user A remembers and attempts to lock, A will either do a get-lock
or a status -u. A response by either that the lock now exists is
consistent with the statement that the accurate data only exists in the
server (Case A) and the only way to get accurate data is to query the
server(Case B).
User A screwed up. You can't make a tool completely immune from human
failure. You can only provide the data the user needs in as clear and
easy a manner as possible and hope that they make proper use of it.
Oh, and to deal with the user's statement that "Subversion must be
broken.." If svn status -u or svn get-lock return a statement or value
that lets user know that "File X was locked since working copy was last
updated" then the user can't say that subversion was broken. Then you
prevent your error case *AND* provide the maximum data value.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 14 17:10:25 2007