[Kemono] Invert download order of revisions

[taskhawk]

Would it be possible to invert the download order of revisions for Kemono? Now that I have taken a look at revisions, I tried to organize the files in a specific way but couldn't due to the current download order where newest revisions get downloaded first.

I'm only interested in the files. I'm writing the file hash in the archive to prevent duplicates, and I'm using the revision_index in the filename to note the revision it came from like a version number. Something like this for simplicity:

"kemonoparty": {
      "archive": "~/kemono.sqlite3",
      "archive-format": "{subcategory}_{user}_{id}_{hash}",
      "directory": ["kemono", "{subcategory}", "{username}"],
      "filename": {
        "revision_index > 1": "{id}-{num:>02}{revision_index:?v//}.{extension}",
        ""                  : "{id}-{num:>02}.{extension}"
      },
      "skip": true,
      "revisions": "unique"
    }

With the current download order the files get processed like this:

./kemono/fanbox/artist/555555-01v3.png
./kemono/fanbox/artist/555555-01v2.png
./kemono/fanbox/artist/555555-01.png

With this config if all three files are actually the same I end up with just one file named 555555-01v3.png which is a bit weird because it really came from the first "version". On the other hand if the revision download order was inverted it would be processed like this:

./kemono/fanbox/artist/555555-01.png
./kemono/fanbox/artist/555555-01v2.png
./kemono/fanbox/artist/555555-01v3.png

And if the files are the same I should end up with 555555-01.png which seems more appropriate. If the files are different then the result should be the same with either download order. It's really for this kind of scenario where it's necessary.

[mikf]

Would a value representing the total number of revisions (revision_count?) also work, so that it would be possible to enumerate revisions in reverse? ({revision_count - revision_index + 1} in an f-string)

I could also just add a order-revisions option that reverses the revision list before it gets processed, but that might have unintended effects on other revision:… values. Not sure.

Maybe I'll just do both.

[taskhawk]

Would a value representing the total number of revisions (revision_count?) also work, so that it would be possible to enumerate revisions in reverse? ({revision_count - revision_index + 1} in an f-string)

Yes, that would work too. When I tried workarounds I actually thought of doing that but found out there was no revision_count. This is probably the easiest fix. It just needs to take into account the "revisions": "unique" option.

I could also just add a order-revisions option that reverses the revision list before it gets processed, but that might have unintended effects on other revision:… values. Not sure.

Not entirely sure either but I would think that as long as the default order remained the same as it is now it shouldn't affect current configs.

[mikf]

Added revision_count metadata (1418c0c) and an order-revisions option (03a9ce9).

[taskhawk]

Thank you!