> 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.
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
I'm only talking about improvement here, not perfection. And after one
improvement is made, whoever wants the next improvement can work on it.
> 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.
> 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.
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
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Apr 26 00:27:24 2006