"Reedick, Andrew" <jr9445@ATT.COM> wrote on 11/27/2007 09:56:45 AM:
> > > 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.**
ALL file contents are potentially out of date the moment you update
your working copy. There is NO guarantee any changes you make can
be easily merged with what others have done since your last update.
> 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.
You are assuming I want to know what files are safe to work on. I want
to know what files are POTENTIALLY unsafe to work on. I will check
the repo if I want the true status. People work in different ways.
You said the information "is useless", but then gave an example where
it was useful...
> 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.
Not having to contact the server is the reason.
Showing status information in a GUI as another reason.
(Caching this information significantly reduces server load and removes
the dependency of a constant network connection when using the GUI.)
This information is NOT dangerous if it includes the wall clock time
the data was gathered.
The original scenario was a file that is not normally locked (no
svn:needs-lock).
As an user I would not normally lock this file to make modifications.
Therefore
I would not normally "svn lock" the file before working on it to see if it
was
locked. Some user needs to make a large change to the file and decides to
svn lock the file to help inform users of the large change. I start
modifying
the file and when I try and commit, I see the file is locked. I am now
angry
at subversion for not informing me this file was locked when I updated my
working copy.
It had the information, but just threw it away.
Yes, a team should communicate outside of subversion. For a large team,
say 250
developers, it isn't feasible to communicate all changes to everyone.
Subversion
could help here, but doesn't. (And maybe it shouldn't, but other CM
systems do.)
Many people are making lots of assumptions about how users would use this
feature.
Any assumptions are bad!
Kevin R.
Received on Tue Nov 27 17:54:56 2007