brane@xbc.nu writes:
> >Anyway, this is one reason I am skeptical about explicit locking: in
> >the back of my head, I'm always wondering if there isn't some
> >difficult individual on the team who's the real problem. It's a shame
> >to impose annoyances on all the people who do work well with the group
> >just because of a jerk or two.
>
> IMHO (strict, explicit, mandatory, whatever) locking is more about
> preventing accidents than about forcing policies down peoples' throats.
As I understand it, there are two distinct sorts of harm we're trying
to prevent:
- people corrupting or wiping out others' work in the repository, and
- people working on documents locally, only to find out that they
can't commit their changes.
Preventing the first sort of lossage is straightforward: changes only
enter the repository on a commit, and the commit can just fail with an
error message. This is never a problem.
The second sort of lossage is tougher. What's necessary here is a
reliable reminder that the file is being edited by someone else. I
think we all agree that something that the user has to check manually
isn't helpful. So it has to be something that happens automatically.
Now, Emacs can be given hooks that say the right thing at the right
time. I wouldn't be surprised if Microsoft apps have similar
facilities. But for people editing with vi, or ed, or any other
VC-unaware application, the only way to deliver that reminder when
it's needed is to make the file read-only. Almost every tool will at
least warn you before letting you make changes to a read-only file.
So the writeable bit is pretty much the only widely effective signal a
VC system has. It's not a very articulate signal --- "Why is this
read-only?" [silence] --- but it's all we've got.
Overall, the goal here must be to communicate something to the user,
not to try to force them to behave a certain way. But it seems to me
that some of the mechanisms described go beyond facilitating
communication, and try to force behavior --- which is both obnoxious
and ineffective. I could be misinterpreting the intent, but that's
the transgression I object to.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 19:07:57 2002