RE: Atomicity of locks and needs-lock

> You lock a file to protect yourself. You set svn:needs-lock
> on a file to protect others.

You lock a file to protect whoever would've committed last. Maybe
you're protecting yourself, maybe you're protecting others. It all
depends. The point is, whoever is faced with that merge, it is likely
to be difficult or impossible.

Svn:needs-lock is persistent. The presence of needs-lock indicates that
a merge is persistently difficult or impossible.

A lock is temporary until next commit. The presence of a lock indicates
that a merge is difficult or impossible until the next commit.

> They are thinking *they* do not want to merge any changes you
> might make. You might know better (because you know what
> change you're going to make), or you might be in a better
> position to do such a merge.

If you know better, or you're better suited to merge, you are allowed to
override the read-only bit and edit the file anyway. Merge your changes
after the lock is released.

The remote person only got the lock because they thought it was *likely*
that their changes and your changes would be difficult or impossible to
merge. If one of your colleagues is nonproductively locking for easily
mergeable changes, you should talk to them and maybe complain to the
boss.

> > No user has reason to lock a file, unless they believe that you
> > shouldn't work on it right now.
>
> No, unless they believe you shouldn't *change* it right now.

What's the difference? Work on a file = Change a file, as far as I'm
concerned. Perhaps the comment was meant to simply be argumentative.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 30 01:06:37 2006