4 ms·

"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there." I disagree

"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there." I disagree. Mercurial is famous for its "simple" revision numbers that differ between repositories. These revision number are magical as they can suddenly change when you merge some branches and older commits get pulled into your history. Since mercurial and git are mostly about collaboration, non-stable identifiers can be very confusing.

gecko 13y ago
They can't change in a given repo unless you use history-modifying extensions. They do differ between repos. Most modern third-party tools, including Kiln, hide them by default for this reason.
- oleganza 13y ago
  Thanks for clarifying this. I haven't touched mercurial for a while.
mrtngslr 13y ago
Revision numbers are stable within a given repository. The revision number for a commit is simply the index of the commit in the changelog — nothing more. Since a changeset must come after its parent in the changelog, the revision numbers give you a topological ordering of the changesets. A topological ordering is often not unique — this is why revision numbers can differ between repositories, even if they contain exactly the same commits. Because the changelog is append-only, new commits you pull in get higher revision numbers than the existing commits. Your existing revision numbers will thus not change when you do 'hg pull' and 'hg merge'. We don't actually guarantee that revision numbers cannot change when you pull, but it's been the case until now. In any case, the stability of the revision numbers isn't why we like them — we like them since it's often easier to type 'hg histedit 12345' than 'hg histedit c38c3fdc8b93' when you've looked up a particular changeset in your (local!) repository. Hosting sites like Bitbucket and Kiln will wisely not show you revision numbers since the concept is meaningless when talking about more than one repository.

gecko 13y ago

They can't change in a given repo unless you use history-modifying extensions. They do differ between repos. Most modern third-party tools, including Kiln, hide them by default for this reason.

oleganza 13y ago
Thanks for clarifying this. I haven't touched mercurial for a while.

mrtngslr 13y ago

Revision numbers are stable within a given repository. The revision number for a commit is simply the index of the commit in the changelog — nothing more. Since a changeset must come after its parent in the changelog, the revision numbers give you a topological ordering of the changesets. A topological ordering is often not unique — this is why revision numbers can differ between repositories, even if they contain exactly the same commits. Because the changelog is append-only, new commits you pull in get higher revision numbers than the existing commits. Your existing revision numbers will thus not change when you do 'hg pull' and 'hg merge'. We don't actually guarantee that revision numbers cannot change when you pull, but it's been the case until now. In any case, the stability of the revision numbers isn't why we like them — we like them since it's often easier to type 'hg histedit 12345' than 'hg histedit c38c3fdc8b93' when you've looked up a particular changeset in your (local!) repository. Hosting sites like Bitbucket and Kiln will wisely not show you revision numbers since the concept is meaningless when talking about more than one repository.