> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
>
> Bicking, David (HHoldings, IT) wrote:
>
> >
> > 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.
Then why did you assert that I was advocating this for unmergable files,
then ask irrelevant questions?
>
> > 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.
THAT to me, is a major problem in team culture - worse than locking
files without permission. 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.
> > 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.
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.
Regardless, even if it were relevant to the issue, I think knowing that
a dozen files are erroneously locked simply by looking at your IDE is
actually ALSO quite useful - don't you? How better to resolve the
problem than by having it presented in a clear and obvious fashion?
> 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.
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.
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.
Does anybody else out on this list care one way or the other?
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
*************************************************************************
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 Tue Nov 20 19:56:59 2007