> -----Original Message-----
> From: Reedick, Andrew [mailto:jr9445@ATT.COM]
>
> > -----Original Message-----
> > From: kmradke@rockwellcollins.com
> >
> >
> > > 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.
>
------------- snip ---------------
> 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.
Why, oh why do people who don't want this define scenarios that are:
A) Extreme to the max
B) Not the point of the feature request
Here's an outlandish comparison:
Me: "I want a roof on my house to protect me from things falling from
the sky, like rain and snow."
Random person(RP): "A roof is a stupid idea! Look what happens when a
tree falls or a meteor drops out of the sky! See? Roofs are useless,
so don't use them."
Me: "But a roof keeps me dry and traps heat..."
RP: "yeah, but it doesn't ALWAYS do that! As soon as you get a leak or
the wind rips it off, you'll get wet, and thus the roof is a waste of
resources."
Me: "But most of the time, it works, and if it doesn't, I can repair
it."
RP: "If it doesn't handle the meteor, it is useless, and I won't build
one for you."
Me: Reaching for my tools, "*sigh*"
Listen to this: in any shop that is using Subversion locks will be
uncommon. Uncommon is similar to rare, infrequent, and only when really
really important. You just described an extreme scenario that _could_
happen if there is absolutely no leadership, absolutely no intelligent
communication, and absolutely nobody on the team who knows or cares
about productive software development or team work. This is a scenario
for a team of imps seeking to screw over everybody around. Will they
succeed? Duh.
Now, for 90%, and most likely 99.9% of functional teams or groups of
teams, reasonably intelligent professionals will be working on
reasonably divided work with plausible expectations. ONCE IN A WHILE
there will be a MAJOR change necessary on A FEW INDIVIDUAL FILES.
Follow me so far?
When that happens one ADDITIONAL level of communication that would be
useful is to be able to see when that happens in source control. Sure,
a lock might be released or taken the same millisecond you are updating,
and you might miss the lock. Are you any worse off than now? Think
about it for a minute. MOST of the time, when a file is locked, it will
be because there is a good reason (tm) involving major surgery. In
ideal situations, that fact will have been communicated to the team, but
hey, people forget.
I just want to make a small change to a file, but I see it is locked,
and the reason displayed is a complete rewrite to handle known issues.
Okay. Now I can choose to make my change when the rewrite is done, or
any of a number of other options, rather than hit a wall when I commit
after making the change.
Now what is the real likelyhood that when a lock is attained, and work
commences, that the lock will evaporate and reappear several times while
you're not looking? What is the likelyhood that if you do an update
twice per day that you'll be worse off knowing about a lock than not?
Am I any worse off if a lock is taken by someone five minutes after I
update and begin my work? As I see it, I'm exactly where I am now.
>
> 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.)
With that much spurious locking going on, my resume would be seeing as
many employers as possible. Work would be a waste, and the team should
serialize everything.
>
> 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'.
Actually, no. You're simply no worse off than you are RIGHT NOW,
because that situation still occurs except there is no good way to know,
and the Subversion workflow continues as it is now.
>
>
> 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.
So the only person who should know about a lock is the one who took the
lock, leaving everybody in the dark all the time (unless they constantly
status -u)
> 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.
The solution is neither half-ass, nor unreliable. Anybody with at least
half a brain knows that when they query the server, they get the status
as of that point in time. If they don't, they should be working at
McDonalds, not in a software development team.
>
>
> > 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.
That is a totally illogical argument. Anyone smart enough not to trust
the cached info, will do an update to see the status as of now, then
take action. If the developer is smart enough to lock the file, then
they clearly made the decision that their changes are far reaching and
guaranteed to be a complex merge. Thus, wishing to save team members
work, locks the file with a note about the size of the change. This, of
course, is useless if the other developers CANNOT SEE IT.
> 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.
If they know how to use Subversion, they won't blame it. If they don't
know how to use it, and continue to blame it after they are shown how to
use it, they should be jettisoned as soon as possible, because their
judgement is in question.
> I'm just not seeing any upside to cached lock info.
I see that.
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 27 18:00:10 2007