On Nov 17, 2004, at 12:10 AM, Robert Hunter wrote:
>
> Alice checks out revision 10.
> Bob checks out revision 10.
> Alice accepts a task that requires modifying a file,
> "non-versionable.png".
> Alice runs an update, but her working copy is already up to date.
> Alice sets an attribute "read-only", perhaps with her username as a
> value.
> Alice commits revision 11.
> Alice begins working on the file.
> Bob accepts a task that requires modifying the same file.
> Bob runs an update, and receives the new "read-only" attribute.
> Bob's client sets local filesystem permissions on the file to read
> only.
> Bob begins work on the file, but his editor informs him the file is
> read-only.
> Alice finishes work on the file.
> Alice removes the "read-only" attribute.
> Alice issues commits revision 12.
> Bob updates to revision 12.
> Bob's client sets the local filesystem permissions on the file to
> read/write.
>
You've effectively just described how our upcoming 1.2 'locking'
feature is going to work, the thing I've been working on for the last
month or so.
However, our UI is just a tiny bit different. If a file is generally
unmergeable, then users and admins set a 'svn:must-lock' property on
it. When this property is present, the file is read-only all the time,
for everyone, in every working copy. The idea is that people will
notice the read-only-ness in their editor, and it will remind them that
the file needs to be locked, using an 'svn lock' command. Once a user
has locked the file, it becomes read-write for him. After committing &
unlocking, it goes back to its normal read-only state.
The theory here is that the everyday read-only state will prevent Bob
from wasting hours of work before he ever begins; the file is
uneditable, and when he runs 'svn lock' to make it editable, he
instantly gets an error about how Alice has locked it. Voila, Bob
never wastes his time on unmergeable changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 07:56:12 2004