To a certain extent you can control who can edit what.You do this by normally disabling the fields in which editing must be restricted, and by providing special "editing" workflow steps, each of which is accessible by a different security role; a field template must be associated with each such "editing" workflow step which allows that security role to edit the field to which they have access.

For example, say you have two security roles "Developers" and "Testers". You could define a large text field "Developer Comments" and a large text field "Tester Comments". The "Developer Comments" field is enabled for editing on a field template called "Developer Comment Editing Field Template"; the "Tester Comments" field is enabled for editing on a field template called "Tester Comment Editing Field Template"; both fields are read-only on the default field template. The template "Developer Comment Editing Field Template" is associated with a workflow step called "Being Edited By Developer"; this workflow step can only be selected by a member of the Developer security role.The template "Tester Comment Editing Field Template" is associated with a workflow step called "Being Edited By Tester"; this workflow step can only be selected by a member of the Tester security role.

Users must remember to revert the workflow back to a "non-editing" step before saving, in order to protect their edits from the enemy.

We use this technique to a limited extent for protecting smaller fields. In our experience, users don't intentionally (or accidentally) overwrite other users' edits in large text fields.

If you're wondering why we don't just use field-access security for this purpose, it's because in fact we have lots of security roles for different project areas, and we don't want to have to define special field-access restrictions for every security role just to prevent them from accessing the fields with restricted editing rules, so we do this via field templates instead.