On Apr 13, 2005, at 1:59 PM, SteveKing wrote:
> Ben Collins-Sussman wrote:
>> The sentence you just wrote above -- "users could see that a file
>> needs to be locked" -- is *exactly* the reason the svn:needs-lock
>> property exists. If you're thinking about creating a new icon
>> overlay that means, "you should lock this file before editing", then
>> you should make it into a 1-to-1 correspondence with the existence of
>> svn:needs-lock.
>> So your criteria for showing this new overlay would be:
>> - the file is versioned && file has svn:needs-lock
>> That's all you need.
>
> I know that. But: reading the properties of a file is an expensive
> function call (performance wise, if you have to do it for many, many
> files very fast). So that's not really an option for TSVN because
> overlays can't take long to show them, or the explorer would slow down
> remarkably.
>
Ah, so it seems that you want to implement inverse logic.
The logic should be:
if (versioned && has-no-lock-token)
if (svn:needs-lock is present)
show "should lock" overlay
But you want to do
if (versioned && has-no-lock-token)
if (readonly)
show "should lock" overlay.
But as cmpilato pointed out, those logics aren't equivalent. A file
can be read-only for other reasons besides the existence of
svn:needs-lock. Is this going to cause problems? I forsee lots of
false positives here. Is it worth the performance tradeoff?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 13 21:10:17 2005