- Appended to comment:
drh added on 2009-11-13 14:18:15:
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.
- Appended to comment:
anonymous added on 2009-11-13 02:36:44:
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...
- Appended to comment:
drh added on 2009-11-12 16:41:55:
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.
- Change resolution to "Open"
- Change type to "Feature_Request"
- Change comment to "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""
- Change foundin to "2009-10-11"
- Change private_contact to "6ba147a4218010d3c6ffddc5ed73dc017a44bf3c"
- Change severity to "Minor"
- Change status to "Open"
- Change title to "diagnostics for fossil tag cancel X Y"
- Change type to "Code_Defect"