Bicking, David (HHoldings, IT) wrote:
>> 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.
>
> THAT to me, is a major problem in team culture - worse than locking
> files without permission.
How so? 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.
> At least in the former, there is less chance
> of messing up the code. Your technique could really throw a wrench in
> the works if there is a good reason to take the lock.
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.
>> 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.
>
> There's the straw man again. When did I say anything about "leaving
> locks"? I said having locks, modifying the file while locked. I even
> said they'd release the lock appropriately. Your assertion has no
> relevance to the issue, and while I have plenty of problems, that is not
> one of them.
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.
>> 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?
>
> Um, no. That situation would merit immediate termination and there is
> no excuse for it. The situation I am describing occurs frequently in
> corporate environments for individual files, and often for reasonably
> good cause for short periods of time.
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.
> In some cases it is because an IT department isn't used to the level of
> communication and control that is common in OSS development and they
> need time to adjust. In other cases, there are developers who just
> don't or won't "get it", and that should become apparent quickly with a
> minimal of suffering for others.
I hope you are talking about exceptional cases where team members don't
communicate that kind of change.
> Once again, I ask, is there a compelling reason that this kind of
> information should NOT be supplied to developers? I've repeatedly
> elucidated on several reasons why it should, and have yet to see a
> reason it shouldn't.
I don't think it would break anything to do it, but I'd rather have
merge tracking...
--
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 Tue Nov 20 21:04:11 2007