Re: Atomicity of locks and needs-lock

Edward Harvey wrote:
> Would anybody object to, or favor this idea?

I object.

> When somebody tries to lock a file that doesn't have needs-lock on it,
> atomically also add the needs-lock property. Conceptually, as far as I
> know by all accounts, it makes no sense to ever lock a file that doesn't
> needslock.

What leads you to this conclusion? needs-lock forces users to either lock
the file, or tweak OS filesystem permissions (removing the read-only bit)
before modifying it. It's the kind of thing you'd want to put on, say, a
Word document that many folks maintain.

But there are certainly times that someone might want to lock a file that
generally doesn't need it because that person is about to embark on a major
change to that file. For example, I might want to lock a source code file
because I know I'm going to completely gut and rework every API implemented
in that file. Generally speaking, my file isn't of the type that folks
should have to lock, but this one time I really want folks to stay away from
it until my massive touches-nearly-every-line change is committed.

> Currently, when a person commits, it atomically will
> Commit-and-ReleaseLock.

That behavior isn't forced -- you can provide the --no-unlock option.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand