> From: Jim Blandy [mailto:jimb@red-bean.com]
>
>
> 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.
>
Well, clearly, not when people are paying attention. :)
> 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.
>
Well, how else are you going to facilitate the needed communication at
the appropriate time (whenever someone goes to edit one of these
non-mergeable files) if you don't try to force behavior by making it
read-only?
Given the potential amount of effort wasted, isn't it worth while to
force some behavior on these types of non-mergeable files? (or whatever
other class of files you want to be exclusively lockable)
This is the same reasoning that SCM systems that have advisory locks
(jim bob is editing /foo/bar) force behavior and initially set the file
to read-only.
If the file isn't set read-only then people will forget to take out that
advisory lock, and people won't know they might want to communicate.
I can certainly understand an argument that claimed advisory locks are
kind of silly on easily mergeable files such as source code, but it can
still come in handy and help prevent needless (and possibly complicated)
conflicts.
Indeed, having advisor locks for an open source project with a public
repository might be down right silly depending on the number of active
committers to a project.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 20:01:07 2002