[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-29 19:50:37 CET

kmradke@rockwellcollins.com wrote:
>>
>> Relying on cached lock information implies that you do not care about
>> locks in the first place.
>
> There is a definite disconnect here somewhere. I'll agree that you
> have no need for the usage case I (and others) have described multiple
> times.

The part that I don't get is why you don't set needs-lock if your intent
is to communicate the fact that changes to a file will be difficult or
impossible to merge even if this is a temporary situation. This is what
should tell others that they need to be concerned about locks, whereas
the temporary existence of a lock has no such meaning even though you
might think it does and you might sometimes be right.

I don't use GUI clients much, but I thought someone mentioned earlier
that the needs-lock property is picked up, cached, and made visible
already. Is there some reason this existing mechanism doesn't work for
temporary situations the same as for file types that are always a
problem to merge?

-- 
   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 Thu Nov 29 19:49: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.