[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Communication of LOCKS and CHANGES

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-11-30 15:17:51 CET

Bicking, David (HHoldings, IT) wrote:

>> 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?

Branching works for changes that can be merged or for where the goal is
to have different versions in development either forever (like for
support after a release) or with the incompatible duplication thrown out
after the fact - perhaps after evaluating finished products. But if the
goal is to avoid wasted duplicate work on changes you can't merge, you
have to serialize.

>> 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.

And the point still stands that you find out too late to change your
behavior appropriately to avoid the problem in the first place.
Communicating the needs and intents would be much better than
discovering what's already been done after the fact.

   Les Mikesell
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 30 15:18:38 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.