[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: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-11-30 18:41:23 CET

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Friday, November 30, 2007 9:18 AM
> 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.

As stated much earlier
4), I'm not talking about unmergeable files. Stop acting as if I want
unserialized access to files that require serialization. Just stop. As
I learned it, branching is also used to isolate destabilizing changes
for various reasons. All of which has nothing to do with communicating
dynamic locks to SVN users.

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

One of the many fine points you refuse to accept is this: Only

Another one: when it is too late, you're still no worse off than without
communication. (see:
) As asked in all those messages, how is the end user worse off because
of lock communication? We have plenty of situations where they are
better off. If you want to continue arguing the point, give me
objectively verifiable reasons why the feature makes using subversion
harder, or working more difficult, or the development process more
challenging. If you can't, just drop it.

> Communicating the needs and intents would be much better than
> discovering what's already been done after the fact.

I agreed with this weeks ago, stop waving it around as if I disagree
with it or am advocating that it not be done. In fact, the idea adds
another venue to supply this information before or during the fact.

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 18:42:02 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.