Bicking, David (HHoldings, IT) wrote:
>> 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"?
If 'svn lock' succeeds, it tells you that no one else has a lock and
that they won't in the future unless they steal yours. And it will make
other commits fail while you hold it. It doesn't mean anything else.
> It looks to me like
> you're saying that even for temporary situations, the svn:needs-lock
> property should be used.
needs-lock is what tells other people that they should be concerned
about locks on some particular file and should obtain one (the only way
to know someone else's doesn't exist) before making changes.
>>> 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?
It's not something you can know for sure in the present unless you set
your own. You can only know that the last time you checked there was
not a lock.
> 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.
You don't know what you'll see if you update - and the lock state only
applies to that moment in time unless you take one yourself. But this
is the same for any update, locked or not. If you want to pick up
others' changes, you should be updating often and you won't know what
you'll get until you do it - even if you just did a 'status', a new
commit may have just completed by the time you do an update.
>> 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.
But yet you say it doesn't work for you... I'm saying that it can't
work. If I understand your reasons, you want to believe that a
momentary locked state means that someone else will commit a
difficult-to-merge change, releasing the lock in the future (even though
this is a file where locking is unusual and not expected) and you want
something to remind you of that possibility. But they could just as
easily change their mind and release the lock with no changes. Or they
could be run over by a beer truck and never release the lock. Or the
lock could have been set by accident and forgotten.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 26 19:11:26 2007