> The problem is that changing a property requires a commit, so
> using such a method would mean 1 extra commit to set the
> needs lock, and all the handling to go around that. Then if
> you release a lock without commiting, it has to unset the
> needs-lock with another commit again.
Ok, How does this sound --
If a person clicks "get lock" on a file that doesn't have "needs-lock,"
then...
- During the "get lock" dialog, display a checkbox (selected by
default) to also set "needs-lock."
- If the person leaves this checkbox selected and hits OK, then...
- Set the needs-lock property.
- Commit
- Get Lock.
- If the person clears the checkbox and hits OK, then...
- Just get lock. (doesn't make any sense, but what can you do...)
If a person clicks on "release lock," and the file has "needs-lock"
then...
- Display a choice:
- "Remove the needs-lock property" or "Nobody can edit without a new
lock"
- Present a checkbox to save this decision for future times of
"release lock"
- If the person chooses "Remove the needs-lock property" then...
- Remove the needs-lock property
- Commit
- Release lock
- If the person chooses "Nobody can edit without a new lock" then...
- Release lock, but keep the needs-lock property.
Does this sound reasonable to everyone?
Received on Thu Apr 27 23:20:13 2006