> -----Original Message-----
> From: kmradke@rockwellcollins.com
> [mailto:kmradke@rockwellcollins.com]
> Sent: Monday, November 26, 2007 6:59 PM
> To: users@subversion.tigris.org
> Cc: Bicking, David (HHoldings, IT); Erik Huelsmann
> Subject: Re: Communication of LOCKS and CHANGES
>
>
> > That being said, I think the non-lock-related part of David's
> > suggestion has some merit. Noting that a given file had
> been changed
> > on the server is useful information with IMO much less risk of
> > confusing the user, even if somewhat out of date.
>
> Just as information that a file was locked the last time you
> checked is useful information to some people. Retaining no
> information is not value enhancing and isn't helping to
> protect the users from themselves.
The issue isn't that information is useful. The issue is in the
actions you take in response to that information. If lock information
is important to you because it affects how you work on files, then the
only 100% complete and reliable solution is to lock the file. You
cannot make informed decisions based on out of date lock information,
and **all lock information is out of date before the svn status or
update command even finishes running.**
Cached lock information is useless because it cannot tell you
which files are safe to work on. Cached lock information can tell you
what _not_ to work on, but not what you _can_ work on.
Cached Lock Info is "Useless" Scenario:
You ran an update. There are 10 files that you want to work on.
As of the update, 5 of those files are locked.
You don't know it, but 5 minutes after you ran the update, 3 of
those 5 files are still locked, 1 lock was removed (file wasn't
updated,) 1 file was updated and the lock removed, and 3 of the other
files that you want to work on have been locked by other people.
End result: 4 of the 5 locked files are still locked (3 locked
plus the 1 updated file,) there's 1 file that you could work on (the
lock was removed) and 3 additional files that you think you can work on
but are actually locked. 7 of the 10 files are untouchable but you're
only aware of 4 locks (5 if you count the false positive.)
So there you are, ignoring the 5 "locked" files, and working on
the other 5 (of which 3 are locked.) You just shot yourself in the foot
six minutes into the day because you couldn't be bothered to run 'svn
lock'.
The whole reason for locking a file is to prevent someone else
from working on it (binary files, want to prevent complicated merges,
etc..) At best, relying on cached lock information is a
haphazard/inconsistent/unreliable way of "avoiding" merging issues.
Relying on cached lock info is doubly sinful because there already
exists a 100% reliable way to lock files, namely 'svn lock'. There's
just no good reason to rely on a half-ass, dangerous solution when
there's an easy-to-use, reliable solution already available.
> Assuming the file isn't locked because the cache says it
> isn't locked is no worse than assuming the file isn't locked
> because you have no information about the lock status. In
> either case you would have to merge your potentially
> incompatible changes and in both cases you should have been
> smart enough to query the server if you wanted the true
> almost real-time status.
Anyone smart enough not to trust the cached info would be smart
enough to lock the file in the first place. If that smart person
doesn't want to lock the file, then they're smart enough to realize that
they're willing to merge. Either way, the cached information is
superfluous.
Anyone not smart enough to understand the implications of cached
lock information is going to cause problems, because they're eventually
going to work on an "unlocked" file or ten. And then blame Subversion
for providing wrong information. Cached info has gone from superfluous
to dangerous.
I'm just not seeing any upside to cached lock info.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 27 16:57:30 2007