> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, November 20, 2007 2:58 PM
>
> 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.
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.
> > 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.
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.
>
> >> 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.
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.
>
> >> 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.
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? 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 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?
> > 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.
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. We also have an excellent team that should be able to
adjust with a minimum of trauma. The feature I suggest would further
decrease that trauma for us and others.
>
> > 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...
Is it really an either/or choice? I find that difficult to believe.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
I'm going to respond to the other messages in my inbox on this topic,
then respectfully withdraw my argument. I've laid out everything in
clear, concise language and still cannot get people to understand the
value of this feature. I, and most people in my company, are alone in
feeling this is useful.
--
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
Received on Wed Nov 21 16:09:12 2007