imagine two users using the cgi interface:

* user A starts to edit an issue
* user B starts to edit an issue
* user A commits his changes
* user B commits his changes

when B commits, the changes A had committed
will be reverted. This problem could be solved
by adding a hidden field in the form that identifies
the version of the issue this change is relative to.
Then, on commit, the diffs could be computed and
be applied to the current version, i.e. merging the
change in, instead of copying it over.

Logged In: YES 
user_id=707416

Could this be implemented with an "@lastactivity=..."
using the last 
activity time as the "version" identifier?

Logged In: YES 
user_id=6405

That's how I was going to do it. Or rather, 
@activity@designator so we can have an activity timestamp 
on each of the classes/items being edited. The cgi form 
handler can then pluck that info out and reject edits as 
appropriate. 
 

Logged In: YES 
user_id=469548

I don't think we should be merging the changes
automatically. Person A may not have changed the fields
which person B has changed, but that doesn't person B
shouldn't take person A's changes into account. For example,
person B closing the issue because of lack of response /
information from the submitter, while person A just posted
more information.

I think we should just tell person B that someone has
committed some changes between his reading of the issue and
his changes,  and let him/her decide what to do with those
changes.

Logged In: YES 
user_id=6405

I'm in complete agreement, Johannes. 

Logged In: YES 
user_id=764

Whether or not two parallel modifications are in conflict
to each other or not depends on the semantics the
tracker (instance) designer put into the scheme.
Wouldn't it be possible to use detectors to determine
whether or not the second checkin can go in or whether
it should be refused / sent back for updates ?

Logged In: YES 
user_id=469548

Nope, it's not possible to use detectors here. Collision
detection needs to access the form data directly, to get the
@lastactivity data out. I've checked in a simple version
that always rejects edit collisions, but I think it'll be
flexible enough to allow for intelligent merging too (by
overriding EditItemAction.handleCollision).

As a reminder to myself (but someone else can pick it up as
well ;), listing what changes user A actually made would be
nice.