When trying to remove a tag (actually I just want to remove it then regenerate it with --propagating set, but I digress) the command "fossil tag cancel X Y" gives no diagnostics when X does not exist.  Eg, try "fossil tag cancel XXXXXXX trunk"

<hr><i>drh added on 2009-11-12 16:41:55:</i><br>
Because Fossil is distributed, it has no way of knowing whether or not the
tag exists.  It can check its local repository, certainly.  But you don't
necessarily want to fail the cancel in that case because the tag might exist
in some other repository that you just have not synced with yet.

I will convert this to a "feature request" to issue a warning if the tag
does not exist in the local repository.

<hr><i>anonymous added on 2009-11-13 02:36:44:</i><br>
So you're saying if a tag doesn't exist locally, but you cancel it anyway, then do a sync which would create the tag locally ... it gets cancelled at that time?  That would certainly violate my own principle of least surprise!

Related question: what if you sync two repos, each of which has tag FOO on commit BAR, but one of the tags is marked --propagate and the other is not.  I assume the --propagate marking wins in this case?

The semantics of tag creation/cancelling and syncing repos seems pretty subtle...

<hr><i>drh added on 2009-11-13 14:18:15:</i><br>
The "tag" artifact with the most recent timestamp wins.

A distributed, disconnected database (such as fossil, but also git, hg, etc) 
exhibits many surprising behaviors if you are used to working with a localized,
monolithic, and always-connected database.  This is an inherent property of
distributed and disconnected systems, I'm afraid.