nous au boulot c'est simple: svn et rien d'autres, juste parce que les révisions sont numérotées. On m'a opposé un niet concerté pour git parce qu'on n'est pas capable de dire facilement si le commit b16b00b5 est arrivé avant ou apres le commit cafefade
En effet, comme l'indique Godzil, c'est trivial d'avoir des commits numérotés avec Git, grâce aux tags Git, qui sont des étiquettes atomiques et non une lourde copie figée de tout l'arbre des sources quand on fait un checkout du repository complet comme en SVN... (*)
Tes collègues n'ont pas voulu admettre que le hash SHA1 ou son préfixe réduit ne sont pas les seules formes possibles pour référencer des commits, qu'il suffit d'utiliser un tag Git 0.1 pour pouvoir ordonner "0.1-234" et "0.1-345" (qui ne sont pas moins clairs que les révisions SVN r234 et r345) ?
Moyennant d'utiliser toujours le delta entre la révision actuelle et le dernier tag Git (comportement par défaut de `git describe`), on peut aussi réaliser un ordre total sur les commits. Avec 0.2 descendant de 0.1 et 0.1-345 antérieur à 0.2, 0.2-234 est ultérieur à 0.1-345.
*: dans mon miroir du repository de mon premier boulot, que j'ai conservé puisqu'il s'agit d'un projet open source, les tags SVN, branches SVN, et autres sandbox et répertoires spéciaux (je ne pouvais pas utiliser le layout standard de SVN puisqu'on utilisait plusieurs répertoires agissant comme branches, et je crois qu'à l'époque, mes essais de spécifier plusieurs arguments branches n'avaient pas donné les résultats espérés), sont responsables de l'immense majorité des plus de 140000 fichiers dans plus 60000 de répertoires de mon checkout, représentant 5 ans après toujours presque 10% des entrées dans les tables de cette partition.