--On Thursday, October 14, 2004 9:43 AM +0200 Julian Reschke
<julian.reschke@gmx.de> wrote:
> I'd call a client that requires a LOCK before GET a poor implementation (if
> it only wants to read the file). A LOCK doesn't guarantee you the "youngest"
> revision any more than GET. All it guarantees is that nobody changes the
> resource between the LOCK and the GET (so you win exactly nothing compared
> to doing the GET right away).
No. The initial argument was that 'svn lock' implicitly does 'svn update.'
Therefore, if we go down this path (which I don't want us to, FWIW: they
should be separate operations), I believe the ordering is critical because
'svn lock' is implying that the user has the absolute latest version before
they do a write operation locally. If you did a GET and then a LOCK, it's
feasible that you don't have the latest version locally and the 'svn lock'
behavior doesn't match the expectation. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 06:38:40 2004