Bicking, David (HHoldings, IT) wrote:
>> Why do you think someone who locks would make the
>> correct change? Everyone else with commit rights still has
>> the option to wait for the lock release and then clobber it
>> with their version anyway.
>
> Sure, but at least the person making radical changes won't have to
> additionally deal with merging a change that is no longer relevant. The
> person who committed that irrelevant change could have avoided doing so
> if she knew about the work ahead of time. You're pretty much saying
> that locks are useless and should be entirely removed from the system.
No, I'm saying that there are version control systems where locks are
expected and people can't do concurrent work. Svn isn't one of them,
although if you want that style the needs-lock property can provide it.
I think most people using svn consider the ability to work
concurrently to be an expected feature - and bumping into locks if you
happen update at just the right time isn't a good way to communicate a
change in expectations. Setting needs-lock might be more reasonable if
done soon enough that everyone will pick it up.
>> If there is a good reason, then there is a good reason to
>> inform others that any concurrent work will be wasted.
>> Otherwise I don't see why you should assume that the locker's
>> changes are any more valid than the changes someone else had
>> done. And if there is any question about which is right,
>> you'd want both committed somewhere so you don't lose either.
>
> This statement advocates that communication is good, useful, and
> critical in any fashion OTHER THAN through Subversion. This statement
> concludes the communication is only useful if it isn't visible in
> Subversion. Sure, I agree that informing others is ideal. Why is it
> bad to also do so via Subversion? Because it might be out of date?
> Bogus.
It might also be incorrect. If files aren't usually locked, I'd expect a
lingering lock to be something that someone did accidentally and forgot.
On a file with needs-lock, it would make sense.
>> The 'update at the right time' is relevant any way you look
>> at it. If you start your work before this unexpected lock is
>> taken you are still going to be wasting your time, and if the
>> need for this difficult-to-merge change isn't communicated,
>> you may still think your version is better and replace it.
>> And you may very well be right.
>
> Okay, so we should then guarantee that the developer will not have the
> information, correct? We should ensure that he will never be able to
> see that maybe he needs to take some action before initiating his work.
> Ever.
Yes, a guarantee that you can't get information through a mechanism that
can't provide it accurately (except by attempting to take your own lock)
should encourage you to use a method that will actually work.
>> I don't see the difference in introducing difficult-to-merge
>> changes in a single file while letting others waste their
>> time with duplicate work or in doing it across multiple
>> files. The 'good causes' need to be communicated so that
>> others don't undo it after the fact anyway.
>
> No difference? One might affect one or two other developers for a few
> hours. The other likely will screw up all work for potentially days.
> One can be handled by two or three individuals who want to work on the
> same code collaborating, the other requires a complete resynch of all
> workspaces, and technical lead intervention. You truly don't see a
> difference? Not even in scope?
No, there is no way to pre-determine how much time would be wasted in
concurrent work doing incompatible changes to a single files vs.
multiple files. These things don't have inherent size/work/time limits.
> Do you believe that an individual who is
> assigned a task should know before starting the extent of the changes
> required, and inform the entire team (possibly 100 or more people)?
> That's a lot of email, or a whole lot of meetings.
You always have to compare this to the wasted work all these people will
be doing when they don't know the plan.
> You don't think it
> is reasonable for an individual to lock a file, attach an explanation
> for the lock, and continue work and let the two or three other
> developers who have to modify that code contact him if they're impacted?
> No value to that?
Not if the others have checked their copies out before the lock is set
and already have work in progress.
> Unfortunately, in corporate environments, this is not as exceptional as
> I would like. It is, however, a reality. It takes time to change, and
> it takes support from management. Fortunately for me, in my situation,
> I have both.
This is why I think breaking the lock or checking in the concurrently
done (and perhaps better) other version(s) on top of the one that took
the lock is a reasonable thing. In a corporate environment there is
some incentive to make sure time isn't being wasted so it is best to
make that visible when it happens.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 18:03:14 2007