Re: Communication of LOCKS and CHANGES

Bicking, David (HHoldings, IT) wrote:

>>> Given the above it makes sense that:
>>> ====================================
>>> 1. A developer who wants to make a change to a file might
>> have to do
>>> extra work if he makes those changes, attempts to commit, and finds
>>> the file is locked. Why? If the locked file is later
>> committed and
>>> completely altered from his base copy, the merge effort is
>> especially
>>> painful.
>>> 2. Said developer has no reason to specifically look for
>> locks, since
>>> the normal modus operandi is to edit, merge, and commit.
>> I'm missing something here. If you are working with content
>> that can't be merged, why is it normal operating procedure to
>> do the work without obtaining a lock? Or in the problem
>> case, why do only some people know to obtain the lock even
>> though other people are working on the same file? Note that
>> if it really is standard procedure not to lock, there won't
>> be any locks for you to see anyway...
>
> Yes, you are missing something here. Refer to #2 that you quoted, and
> also to item #3, which for some reason you apparently didn't get to
> before replying:

I saw it, and consider that to be the problem, not something technical.

> 3. A lock is dynamically added to a file presumably due to unusal
> circumstances.
>
> It is possible to choose to lock a perfectly normal file, and there ARE
> valid reasons to do so. To see an example, please go back and read the
> paragraph following that list of points you quoted. When a person does
> this, nobody else knows UNLESS that person decides to send a
> distribution email to tell them, OR the team leader tells the other
> committers in some fashion.

Yes, communication among the people doing the work would be a good
solution when the operating procedures are changed. If a file is
unexpectedly locked, I'd expect others to assume is was a mistake and
break it.

> All I ask is that MORE INFORMATION which is CURRENTLY AVAILABLE be
> presented to the developers in an easier to use format that requires
> less work to attain. Why is that such a terrible thing? I am becoming
> quite frustrated. Can someone at least acknowledge the points I'm
> making, rather than set up a straw man and set fire to it?

OK, I'll acknowlege that if you have people leaving files locked that
others don't expect to be locked you have a problem. But I don't think
making it visible if you happen to update at just the right time is a
general solution. Isn't this approximately the same situation you'd
have if someone decides to rename all your files and juggle contents
around without informing anyone else in terms of the the difficulty for
others in merging concurrent work?

-- 
   Les Mikesell
    lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org