> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
>
> Bicking, David (HHoldings, IT) wrote:
>
> >>> The part that I don't get is why you don't set needs-lock if your
> >>> intent is to communicate the fact that changes to a file will be
> >> difficult or
> >>> impossible to merge even if this is a temporary
> situation. This is
> >>> what
> >
> > You are (effectively) suggesting either:
> > 1. Access to that file be serialized as policy (permanent
> use of the
> > property), or
>
> If serializing access wastes less time than conflicting
> concurrent work, this would be appropriate.
Amazing. You continue to consciously miss the point. It must take
quite a bit of effort, because I've been clear on this so many times it
boggles my mind.
>
> > 2. To temporarily lock the file, the user will create at least two
> > extra revisions, assuming you know exactly which files need to be
> > locked before you act. More likely, several revisions will be
> > generated as you realize there are other files that need to be
> > modified. This to me is massively inefficient and makes
> absolutely no sense.
>
> There might be more convenient ways to communicate your
> intent - like saying so ahead of time in an email or group
> meeting/call, but if not, this seems like the right way to
> let others know that work on these files must be serialized
> for some duration and keep them from wasting their time. And
> if you are doing this piecemeal, remember that someone else
> could be making their conflicting changes in the opposite
> order and never run into your locks.
Again, consciously making an effort to miss my points. As I said
previously, there is (as yet) no identifiable logical and verifiable
reason that you've described which shows that communicating lock
information causes harm. There is no further point in discussing this
because you will not acknowledge the points and purposes I presented.
Instead, you come up with outlandish situations and point out failings
to handle purposes I never asserted.
As I said before, the only reason I'm even continuing to respond is to
point out the flaws in assertions made against lock communication,
rather than let them stand forever. I've already accepted that the
feature won't be even considered. You have a choice now. Either
continue to distort the situation and consequently see to my replies, or
just say it won't be considered for implementation by the current team,
and let it go. Personally, I don't want to continue this.
> > Now, given, if the change in question gets beyond two files, it is
> > probably worth a task branch. Anything less than that, and
> a branch
> > is overkill.
>
> Branching doesn't really avoid the problem with wasted
> concurrent work that can't be merged - it just isolates it
> for a while.
This has quite a bit of value, don't you think, or am I also
misunderstanding the purpose of branching?
>
> >>> should tell others that they need to be concerned about
> >> locks, whereas
> >>> the temporary existence of a lock has no such meaning even
> >> though you
> >>> might think it does and you might sometimes be right.
> >
> > Please explain why the temporary lock feature exists. I thought I
> > knew, but I am beginning to suspect I am incorrect.
>
> A lock is an enforcement mechanism, not a declaration of
> intent. Using it that way would be like finding out your
> spouse isn't happy by noticing that the locks have been
> changed on your house.
Horrible analogy. Here's the accurate version of that analogy. Right
now, you find out your spouse isn't happy by discovering your locks were
changed. With lock communication in force, if you are paying attention
to your spouse, you will know something is up when you call her and she
says "Don't bother coming home. I changed the locks!".
Armed with this information, you now can make a choice (go home and
stand pointlessly in front of the door, or ask a friend to let you stay
over for the night while you figure a way to fix the situation). If you
were not listening (you didn't check the server), you end up stuck out
in the cold with a useless key.
It's still a bad analogy, but it is more accurate now.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
--
David Bicking
*************************************************************************
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 Fri Nov 30 14:35:36 2007