RE: Communication of LOCKS and CHANGES

//From: Bruce Wilson [mailto:brucetwilson@gmail.com] On Behalf Of Bruce
Wilson

//Bicking, David (HHoldings, IT) wrote:
// -----Original Message-----
// From: Reedick, Andrew [mailto:jr9445@ATT.COM]
// -----Original Message-----
// From: kmradke@rockwellcollins.com
// 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.
        
          

// I'm trying to understand your point here, but it doesn't even sound
// like your proposed solution fixes all the holes.

I never said it would. A pull model never will. I simply want
information available at the time of the pull to be presented to GUI
clients until the next pull.

// Expanding on your scenario: Developer A locks many files with a note
about
// a large change, makes the change and then releases the lock.
Developer B
// happened to have the morning off, and never saw the lock. Developer
C had
// already started making changes to some of those files before the
lock. It seems
// to me that B and C both need to know about A's changes. Since a lock
is
// transitory and not versioned, you can't see the lock details after it
is released.
// B and C will have to learn about A's changes through:

//* A's log message
//* Diffs and normal merging techniques
//* External communication

Yep. How does that invalidate the other scenarios when user B and C can
see when the file they're about to edit is locked? Do you not believe
that this would be useful? So what if they miss the window? (Here's
another one I've repeated multiple times) How are they worse off than
the current situation? How does having the ability to see locks make
their jobs harder? Is the scenario you described any different with
lock display than it is now?

I also am curious why a change radical enough to warrant a lock of
multiple files would be completed only a few hours after it started. In
your scenario, several classes were completely rewritten, unit tested,
driven through test builds, and (hopefully) code reviewed in one
morning. Likewise, do you think it is wise for developer C to go for 8
or more hours without updating their workspace, given that he probably
was informed that a major change was afoot?

Should we all have group meetings that describe exactly which files will
be locked before beginning work? What happens when, inevitably, the
person doing the work realizes another file needs to be included? Does
he stop work until another group meeting when he can tell everybody?
Maybe he sends an email to everybody and hopes they read it? Are any of
these methods any more efficient and effective then _letting_ developrs
see when a file is locked?

Showing locks helps users evaluate how they should act upon the locked
files. This is a good thing.

--
David
*************************************************************************
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