Resume: fossil has no feature by that name. What is it?

Keys: fossil supports PGP-signed checkins but it doesn't provide any mechanism for verifying or revoking those keys. It simply supports signing of commit entries, and at all other times ignores the key wrapping signed commit entries (applying no logic to the key itself).

Migration: if monotone supports exporting using git's format then fossil could import it that way, otherwise you're out of luck unless you want to write a script which checks out each version from monotone and re-imports it into fossil.

To answer the bottom part of your question: "does Fossil support these options? if no, is it on the road map? if no, then why not?"

Fossil has no road map, per se. Either someone is interested in a problem and starts implementing it, or not. There was a detailed discussion about signing of commits some years ago (back in 2011 or 2012, IIRC), but i don't recall what the consensus was. Unless someone takes an interest in the problem and implements it, it won't ever be supported.

As far as the lack of monotone migration goes: in the nearly 8 years i've followed fossil, i don't recall anyone ever bringing up monotone before (so direct-to/from-monotone export/import tool is highly unlikely). git's export format has, for better or worse, long since become the common denominator for converting between SCM systems.

Resume: fossil has no feature by that name. What is it?

It means that Monotone can continue an interrupted synchronization attempt without re-downloading the parts it previously transferred.

Fossil currently doesn't have this because synchronizations are implemented using SQLite transactions: the whole transaction completes or none of it does. That's not to say that Fossil couldn't stash a partial sync somewhere and try to resume it; it just explains why it doesn't bother to do that at the moment.

My initial thought on implementing that is that it would have to store both hash values ("from" and "to") involved in the sync before attempting to resume, and throw away the saved partial sync data if on the second attempt the implicit "to" hash has changed. (e.g. Someone committed to trunk in the meantime.)

Is this really an important feature? How often are syncs interrupted in your world, AnonymousMaybe, and how much time is saved by resuming instead of restarting? In my world, about the only time a sync is interrupted is because I hit Ctrl-C, and most syncs are brief, because I sync often.

The documentation on Monotone's website has an entry for mtn git_export.

I did not realize that Monotone had died. That is very sad. In an abstract sense, Fossil is a spin-off of Monotone. Many of the core ideas of Monotone are copied by Fossil, though Fossil is a completely fresh implementation, without any use or or reference to the monotone code.

For the first part of its life, SQLite was version-controlled using CVS and a wrapper project called CVSTrac to provide bug tracking and a sensible web interface. I recognized that this needed to change, and I searched for an alternative Version Control System (VCS). I looked at monotone. But at the time Monotone would not work as a CGI script - it needed to run as its own server on its own TCP port. That was a show-stopper for me, as I needed to integrate the VCS function into a larger website. I wrote to the Monotone project asking about the ability to support Monotone sync over HTTP, and they besically said that was a bad idea and that I should abandon. If Monotone had had the ability to sync over HTTP, I probably have just used Monotone for managing the SQLite source code. But because Monotone did not support sync over HTTP, I ended up writing Fossil to manage SQLite.

All that said, Monotone pioneered the idea that a "checkin" would be identified by a cryptographic hash of its content, which in turn became the key idea behind Fossil and Git and several other VCSes. So it is sad to hear that Monotone is no longer being maintained.

As for your other questions, I think others have answered them well. I will try to summarize:

"supports resume" - Don't know exactly what this means. The sync mechanism in Fossil is built around HTTP requests. A single sync might consist of multiple HTTP requests and responses. If they is the case, each request/response is independing of all the others, as it ought to be. Maybe this is what you mean by "resume".

"key signed checkins" - Checkins can be PGP clear-signed. I use this on the TH3 repository (a proprietary project). It works.

"revocation of keys" - Though PGP clear-signing of checkins is possible, I know of nobody other than myself who uses it. Nobody else seems to think it is important. As a consequence, not much infrastructure has grown up around it. In particular, there is currently no support for key management. However, the protocol is flexible enough that key management could be added, in a completely backwards compatible way, by a motivated developer.

"migration of monotone to Fossil" - If monotone can export to the git-fast-export protocol, then Fossil should be able import it. On the other hand, git-fast-export is not a well-defined protocol. Most knowledge of git-fast-export must be determined by experiment. So it is possible that Fossil might have issue importing from a git-fast-export file generated by Monotone. If that is a problem, we can probably fix it.

If this is what is meant by Resume then Fossil has already met that requirement.

That's my understanding, which is based on only brief mentions in the Monotone NEWS file and the I2P project's Monotone Guide.

Fossil does have partial sync support already

It does indeed appear that Fossil closes the transaction on receiving each block of data from the remote repository. (That's the last line in the "while (go)" loop that wraps the bulk of the code in the Fossil xfer loop, and there are no continue statements in that loop, so it happens on each iteration.)

When I said that the whole transaction completes or none of it does, I was thinking about checkins, not syncs.

Incorrect. A clone is basically just a big sync, though there are some added optimizations that make it run faster.

Are you having problems? There could be a bug, perhaps, in one of the clone-sync optimizations that prevent it from restarting automatically.

Recently I wrote a post with a number of rambling ideas initially regarding private messages in the forum, then branching out into what it would take to implement that, then exploring other possibilities arising from that necessary infrastructure. In the process, I cover "key signed checkins" and "revocation of keys/trust function implementation". I'd be interested to get your comments, though please post in that thread rather than this one.