La gestion par patches c'est git (et ensuite mercurial, etc).
Non, Git et Mercurial sont tous les deux snapshot-oriented. Si tu parles du commit 14c0f8d3ab6c36672189cd2dd217f4617d12ccba dans Git, il n'y a qu'un état du projet possible pour ce commit, et c'est d'ailleurs à partir de cet état que la chaîne de caractères 14c0f8d3ab6c36672189cd2dd217f4617d12ccba est calculée (en gros un sha1sum du contenu du projet). L'identifiant de commit ne représente pas le changement introduit par le commit, mais l'état du projet après ce changement. Si tu veux un patch, tu dois (enfin, git doit) le reconstruire en comparant le commit et son parent (ou ses parents si c'est un merge).
D'ailleurs, le format de stockage par défaut de Git (avant un git gc) stocke tous les fichiers sans faire de diff.
[^] # Re: Soit j'ai rien compris soit...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
Non, Git et Mercurial sont tous les deux snapshot-oriented. Si tu parles du commit 14c0f8d3ab6c36672189cd2dd217f4617d12ccba dans Git, il n'y a qu'un état du projet possible pour ce commit, et c'est d'ailleurs à partir de cet état que la chaîne de caractères
14c0f8d3ab6c36672189cd2dd217f4617d12ccbaest calculée (en gros un sha1sum du contenu du projet). L'identifiant de commit ne représente pas le changement introduit par le commit, mais l'état du projet après ce changement. Si tu veux un patch, tu dois (enfin, git doit) le reconstruire en comparant le commit et son parent (ou ses parents si c'est un merge).D'ailleurs, le format de stockage par défaut de Git (avant un
git gc) stocke tous les fichiers sans faire de diff.