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

RE: Re: Communication of LOCKS and CHANGES

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-11-26 17:05:34 CET

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Harvey, Edward wrote:
> >> So it sounds like you want to use the "Lock Communication"
> mechanism
> >
> > Actually, I am already familiar with the svn:needs-lock
> property. It
> > is useful for its own purposes, but it's not what I'm
> talking about here.
> >
> > Regardless of the needs-lock property, it is totally
> possible for some
> > user at another location to lock or commit a file. That
> change will
> > not be communicated to you automatically, and at present it is
> > impossible for you to automatically receive that information, no
> > matter what you try. (Unless you want to use needs-lock on every
> > file, and create the needs-lock property automatically on all new
> > files and be forced to lock every file before every edit ... but I
> > think that's overkill.)
> I think you want needs-lock on every file where content
> changes can't easily be merged and multiple people will be
> making changes. Apparently in the case we are discussing,
> this situation is temporary, but it still seems like the
> correct way to communicate the need to lock or wait for
> someone else to release for that time interval.

Les, can you describe the purpose of "get lock"? It looks to me like
you're saying that even for temporary situations, the svn:needs-lock
property should be used.

> > What I'm talking about here is to create the ability, if
> you want it,
> > to let this information be communicated to you
> automatically. If you
> > don't want to use this ability, you don't use it and that's ok too.
> What information? The existence of a lock doesn't provide
> any information except that the lock existed at the time you saw it.
> It doesn't tell you anything else. The person who locked can
> release the lock without making any changes - in which case
> there is no other information to convey.

Are you stating that the fact a file does not have a lock is not
information? If I were to see that a file I want to modify is locked,
and chose to update to see if it remains locked, that I should not see
that it is no longer locked? I consider that to be information.

> > The needs-lock solution is already pretty well implemented, in my
> > opinion. I'm trying to talk about a solution to a
> different problem -
> >
> > The problem at hand is: There is no possibility (presently) to
> > automatically communicate somebody else's changes or locks.
> You have
> > to check manually. I believe this is a useful feature that can be
> > implemented without harming anything else.
> Trying to convey to someone else that concurrent work
> shouldn't be attempted can be done with needs-lock. Just
> creating a lock that can be released with no side effects
> doesn't have any additional meaning.

Ah, so you _are_ saying that "get lock" is useless. I have to disagree
for reasons I already stated repeatedly.

> --
> Les Mikesell
> lesmikesell@gmail.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

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 Mon Nov 26 17:06:27 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.