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.
> 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.
> 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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 21 20:58:04 2007