Edward Harvey wrote:
>> Automation is only good if it's absolutely 'reliable'. With
>> reliable, I mean there must not be the slightest possibility
>> for the information to be wrong or outdated. If it is, then
>> automation just makes the user
>> *think* he's save to do something, even if he might not be.
>> And that's even worse than no automation.
>
> If you don't like it, you don't have to use it. But other people would
> like to have an automatic check for modifications. And if enough people
> felt it's unreasonable to use a short time for the periodic check, it's
> not impossible to create a push model rather than purely pull.
TSVN is a client. If you want a push model you're looking in the wrong
place.
> You absolutely cannot and should not expect perfection. Perfection
> inhibits progress. It is unproductive to expect "not the slightest
> possiblity" that information is outdated. For that matter, not even the
> present model meets that expectation. Two people in the present model
> are able to check for locks, see that there are none, make a tiny
> change, and try to commit. One of them will succeed, and one of them
> will conflict.
Well I expect perfect reliability from a VCS, and subversion guarantees
to avoid this race condition by using svn:needs-lock. If it didn't, the
locking model would be useless. There are almost no situations when you
should use locking without having the svn:needs-lock property set.
When that property is set on a file, it becomes read-only until you
acquire a lock, and only one person can acquire a lock, so no race
condition is possible.
> I'm only talking about improvement here, not perfection. And after one
> improvement is made, whoever wants the next improvement can work on it.
We do not agree that it is an improvement.
>> Subversion does *not* store locks held by others in the
>> working copy, so they're not shown.
>
> Ok, subversion can query for lock status, but it does not store the
> result of that query. This is changeable behavior.
>
>> You can't set the lock owner. That's not a working copy
>> property. It is a rev prop, and only present in the repository.
>> The lock owner is set when you get a lock on a file.
>
> You are able to check for modifications, and see who has lock. It is
> not impossible to store this information.
We would have to cache that information for every versioned file on your
hard-disk. Where would that happen? Not in the .svn folders because we
don't own them.
>
>> But you
>> can't expect
>> us to change the model Subversion is based on just because
>> you want it.
>
> This has been in discussion much longer than me. I'm not the only
> person who ever requested it, or even thought it was a bug that it
> didn't already work. I don't expect you, Stefan, to change anything.
Wrong. People sometimes request that the icons to show repository lock
status, until it is explained that the shellex cannot contact the
repository. AFAIK you are the only person who has requested a periodic
automatic refresh as well.
And on a related note, an automatic update, which you also asked for,
would be a very bad idea. That would result in a file changing while you
are working on it, and since most editors read a file into memory, you
would not even see the update and would just overwrite it with the (old
version + your mods) on saving your changes.
> But yes, yes I can expect to change something if it's an improvement,
> and open software. If you don't like a new feature, you don't have to
> use it.
Bear in mind that you don't have to answer all the bug reports that will
result when explorer becomes unuseable. Stefan does.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Wed Apr 26 01:14:35 2006