(Traduction du texte original en anglais : RevlogNG)
RevlogNG est arrivé avec la version 0.9 de Mercurial (voir aussi Revlog).
Carences du format revlog d'origine :
- la taille de la révision non-compressée n'est pas sauvegardée
- le hash SHA1 est potentiellement trop faible
- le contexte de compression des deltas est souvent trop petit
- l'interval des offsets est limité à 4 Mo
- certaines métadonnées était situées dans les données (par échappement).
Le format d'origine des index se composait comme suit :
- 4 octets: offset
- 4 octets: taille compressé
- 4 octets: révision de base
- 20 octets: nodeid
- 20 octets: nodeid du 1er parent
- 20 octets: nodeid du 2è parent
72 octets au total
Le format revlogNG donne :
- 6 bytes: offset -- Soit la "distance" à parcourir dans le fichier de données pour pointer sur le bon delta
- 2 octets: marqueurs
- 4 octets: taille compressé -- Une fois qu'on pointe au bon endroit, indique la quantité de données à lire pour avoir le delta
- 4 octets: taille décompressé -- Ceci est une optimisation. Ça permet d'avoir la taille du fichier pour cette révision.
- 4 octets: révision de base -- La dernière révision où est stocké le fichier en entier.
- 4 octets: révision liée -- Une autre optimisation. De quelle révision s'agit-il ? De quel commit vient-elle ?
- 4 octets: nodeid du 1er parent -- Révision du parent 1 (expl: 12, 122)
- 4 octets: nodeid du 2è parent -- Révision du parent 2
- 32 octets: nodeid -- Un id unique, également utilisé pour la vérification (hash du contenu + IDs parents)
64 octets au total
Entête revlogNG :
Comme l'offset du premier tronçon de données est toujours zéro, les 4 premiers octets (partie de l'offset) sont utilisés pour indiquer le numéro de version et les marqueurs du revlog. Toutes les valeurs sont enregistrées en orientation big-endian.
RevlogNG permet aussi de combiner les index et les données. Ce qui peut grandement réduire l'espace mémoire utilisé pour de petit revlogs. Dans ce format, les tronçons de données viennent juste après leur entrée d'index. La position de la prochaine entrée d'index est calculée en ajoutant la "taille compressé" de l'offset.
Pour savoir comment sont sauvés les redénominations, voir "Problems extracting renames", une réponse de mpm postée le 12 février 2008, sur la mailing list de mercurial.
Voir aussi : ParentDeltaPlan