Prevent upload of packages with existing x-revision fields.

[peti]

stm-queue-extras version 0.2.0.0 has uploaded a Cabal file that contains a header saying

x-revision: 1

even though no such revision exists. Maybe that shouldn't be allowed?

[dcoutts]

Yeah, good idea.

[gbaz]

updating title to reflect issue.

[tfausak]

I know this is an old issue, but just in case it helps anyone: The x-revision field is useless and should not be used for anything. To quote #779 (comment):

x-revisions fields MUST not be trusted; they're merely an internal implementation detail of hackage; there's no guarantees and clients shall avoid making assumptions about the x-revision field.

At time of writing (2020-07-26), there are many instances of both this issue and #779.

Click to expand table of packages with mismatched x-revision fields.

Package	Revision	x-revision
apiary 0.1.0.1	0	1
apiary 0.2.0.0	0	1
apiary 0.3.0.0	0	1
apiary 0.3.1.0	0	1
apiary 0.3.2.0	0	1
apiary 0.4.0.0	0	1
apiary 0.4.0.1	0	1
apiary 0.4.0.2	0	1
apiary 0.4.2.0	0	1
apiary 0.4.3.0	0	1
apiary 0.4.3.1	0	1
apiary 0.4.3.1	1	2
apiary 0.4.3.2	0	1
apiary 0.5.0.0	0	1
apiary 0.5.1.0	0	1
apiary-cookie 0.3.1.0	0	1
apiary-cookie 0.4.0.0	0	1
apiary-cookie 0.4.1.0	0	1
apiary-cookie 0.4.2.0	0	1
apiary-cookie 0.4.3.1	0	1
apiary-cookie 0.4.3.2	0	1
apiary-cookie 0.4.3.3	0	1
apiary-cookie 0.5.1.0	0	1
apiary-persistent 0.4.2.0	0	1
apiary-persistent 0.4.3.1	0	1
apiary-persistent 0.4.3.2	0	1
apiary-websockets 0.4.2.0	0	1
apiary-websockets 0.4.3.1	0	1
apiary-websockets 0.4.3.2	0	1
apiary-websockets 0.4.3.3	0	1
cookie 0.4.1.5	3	2
effect-monad 0.6	3	2
glirc 2.20.2	3	2
snaplet-fay 0.3.3.13	3	2
snaplet-fay 0.3.3.13	4	3
snaplet-fay 0.3.3.13	5	4
snaplet-fay 0.3.3.13	6	5
snaplet-fay 0.3.3.13	7	6
stm-queue-extras 0.2.0.0	0	1
vivid 0.1.0.1	0	1
vivid 0.1.0.2	0	1
XSaiga 1.1.0.0	0	3
XSaiga 1.1.0.0	1	4

The only way to determine revision numbers is to walk through the index and keep a counter for each pkg-ver. In my opinion Hackage should remove the x-revision field to avoid confusion.