Lost update problem with revisions

[quasicomputational]

Consider this scenario: there is a problem with one of your packages' bounds requiring trustee intervention, and a trustee duly revises the package description. At a later date, you want to revise the package for some other reason, and so you edit the pristine .cabal file on your machine, test it does what you wanted, and then paste that in to the text entry and submit... and now the trustee's revision is lost, and whatever problem they solved with it is likely to recur.

#230 would help here in making it harder to lose revisions to this type of stealthy conflict, but it's not a total solution.

If you're uploading new revisions with a tool, then there could be a total technical solution: the tool can keep track of what the expected revision number is, and ask Hackage to refuse to apply the revision if that doesn't match (i.e., the same mechanism as HTTP's conditional requests, or Git's --force-with-lease).

For the manual upload case, I think maybe requiring the user to acknowledge a warning if they weren't the last one to revise the package would be suitable?

[phadej]

@quasicomputational doesn't x-revision field act as "compare-and-set" protection? Hackage does refuse to apply the revision if x-revision in the new file isn't what it expects.

Errors:

The new x-revision must be 1

[quasicomputational]

Oh, that's useful to know. I'd thought that x-revision was entirely advisory and unreliable. I guess that means this bug is already solved! Maybe there should be some documentation of this somewhere but I don't know where it would go; hopefully any future searchers will find this bug and be enlightened similarly.

[hvr]

@quasicomputational it is unreliable as a means of inferring the revision number; it is however reasonably effective as a simple compare-and-set mechanism for short-term edit conflict detection; for long-term edit conflict detection it's less effective as it depends on how the client-side makes use of it, and naive tooling might easily render it uneffective for this latter situation.