Sequence numbers in DVCS's have a few problems that don't exist in a centralized VCS like SVN:
- The sequence numbering will be different in each repo. This makes a sequence
number completely meaningless without a context repo
- Attempting to use a "centralized" repo as the canonical source for sequence
numbers is unwieldy, and doesn't even work in any workflow besides
hub-and-spokes
- Any time you have to reference a sequence number, you have to talk to
the central repo to figure out what it is. SVN has to talk to its
central repo all the time, so it may not seem like an issue to an SVN
user, but it's a gigantic downside for DVCS users who are used to
working purely offline
- For example, referencing a commit inside another commit message requires knowing this number, which makes it rather difficult to do offline commits.
- Any time you want to mention a revision, you have to figure out the revision you want to reference, and then run a command to translate that to the server revision, and then give that to someone else, and they have to do the same steps in reverse. God forbid they can't talk to the server (e.g. not VPN'd) and can't even do the conversion.
- Setups like GitHub, where users are encouraged to liberally fork the repo and grab commits from each other, are rather popular. This isn't hub-and-spokes, so one of the most popular ways to work with git won't even support sequence numbers
- Any time you have to reference a sequence number, you have to talk to
the central repo to figure out what it is. SVN has to talk to its
central repo all the time, so it may not seem like an issue to an SVN
user, but it's a gigantic downside for DVCS users who are used to
working purely offline
- Attempting to use a "centralized" repo as the canonical source for sequence
numbers is unwieldy, and doesn't even work in any workflow besides
hub-and-spokes
- Sequence numbers will not reflect the creation date of the commit, instead thye will reflect the time at which that commit entered the repo. This means that you cannot know if r660 was made before or after r665. The only guarantee you have is that revision numbers within a stretch of purely linear history will be ordered, and that's not very useful in a DVCS
- What do you do with the numbers if you rewrite history? There's no satisfactory answer.
Key points:
- Referencing revision numbers in any permanent medium (e.g. commit messages) doesn't work
- Revision numbers aren't ordered by commit creation time
- Revision numbers don't translate between repos without a network connection and hassle on the part of the user
Other notes:
One common use of revision numbers in SVN is to reference the parent of a commit, e.g. if you want to diff r660 against it's parent you'd use 659:660. That doesn't work at all in a DVCS, as r659 might reference a commit on a different branch that was created after r660. This only works in SVN at all because of the linear history and the fact that there are no native branches (e.g. a commit r659 on another branch still includes the state of all branches, tags, and trunk). This is solved in git by introducing a syntax for referencing ancestors, e.g. SHA1^ to reference the parent of SHA1.
Pretty much the only benefit left of sequence numbers is the ability to look at one, then type it without using copy&paste (e.g. referencng a commit from a log). Is this worth introducing all the complexities of sequence numbers into a DVCS just for this? Especially since DVCS's usually have other ways of referencing commits (e.g. git's powerful syntax for traversing ancestry graphs, documented in git-rev-parse)