-
hg changeset ID locality
-
Sudden realization: There is a possibility of an hg repo closely following another one to lose sync of changeset IDs (contrary to changeset hashes which are unique). Committing in both, pulling to each other and merging creates different intermediate IDs. I need to remember looking at the chanset ID in the upstream Tx repo before linking to the changeset when closing tickets.

Yep. The only “unique” identifier of a changeset is the full sha256 hash :D
You can get hold of the sha256 changeset ID by referring to the ‘{node}’ in output templates like the one below:
In Python, here’s a short ’standalone’ implementation of the “hg branches” command:
I’ve trimmed
node.hex()output to 20 hex characters, but if you don’t limit the string output you’ll get the full node hash. The active/inactive branch test is also less Pythonic than the similar code in Mercurial’s source tree (see “def branches” inmercurial/commands.py), but it’s probably simpler to understand as an example ofnode.hex()than the list-comprehension version:Anyway, this is getting too long-winded. All I wanted to write as “don’t rely on revision ‘numbers’, use the changeset hash as a UUID of changesets.” If you are worried about the space/time it takes to compare hg node strings, use the hg.node object to store them as raw-data/binary values and convert them to strings only at the last possible moment before display.