Que fait l'option de purge exactement ?
Elle efface tous les anciens State et ne conserve que le dernier qu'elle renomme state_1.
Pourquoi avoir privilégié le SHA-512 ?
Les algorithmes du type SHA2 sont des algorithme de hashage au même titre que MD5 et SHA1 comme indiqué ici: https://fr.wikipedia.org/wiki/SHA-2
J'ai choisi le SHA-512 pour obtenir un minimum de collision. On peut voire ici que le MD5 est déconseillé. https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions
Et de plus, ce qui est lent ca n'est pas l'algorithme de hash, c'est la lecture des données sur le disque.
Par exemple, avec un Core i5 si je ne lit pas les données depuis le disque je peux hasher 3 GB en 47 secondes avec un seul core.
La même chose en MD5 me donne 3 GB hashé en 24 secondes. Ok, le SHA-512 en deux fois plus lent mais je ne pense pas que ca soit l'algo de hash qui ralentisse le plus dans le cas de Fim. C'est le disque.
En conclusion, j'ai choisi SHA-512 pour la longueur de sa clé (512 bits) qui permet de diminuer les chances de collision quand on hash des fichiers énormes.
Pourquoi historiser tous les changements (fim log) ?
C'est pour pouvoir retrouver ce que l'on a fait comme différentes modifications pour arriver dans cet état.
On n'a pas les anciens contenus et on ne peut pas comparer, mais on a pour chaque révision le commentaire de commit et un résumé des modifications qui ont été apportées.
Le fait de conserver les State entiers permet de revenir à l'état d'avant en effaçant simplement le dernier State. Il faudrait que j'ajoute la commande revert pour faire cela.
Si l'historique gêne, on peut l'effacer avec la commande purge.
Est-ce que le hash de 1mb est suffisant ?
En effet, il pourrait suffire. Mais quand on a énormément de fichiers et un très gros volume, le hash de 4kb permet d'avoir un résultat au diff vraiment très rapide.
Actuellement, je n'ai pas assez d'expérience pour savoir lequel des deux est le plus pertinent.
C'est une bonne idée de hasher un 1mb en prenant 3 blocs de 4K disjoints dans un fichier: 1 au début, 1 à la fin et 1 au milieu.
Est-il prévu de traiter à terme des médias en tenant compte de leur type ?
Je n'ai rien prévu de tel. Mais en effet Fim pourrait évoluer avec le temps.
Toute bonne idée est la bien venue et les contributions aussi.
[^] # Re: Trés beau projet.
Posté par Etienne Vrignaud . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
Que fait l'option de purge exactement ?
Elle efface tous les anciens State et ne conserve que le dernier qu'elle renomme state_1.
Pourquoi avoir privilégié le SHA-512 ?
Les algorithmes du type SHA2 sont des algorithme de hashage au même titre que MD5 et SHA1 comme indiqué ici: https://fr.wikipedia.org/wiki/SHA-2
J'ai choisi le SHA-512 pour obtenir un minimum de collision. On peut voire ici que le MD5 est déconseillé. https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions
Et de plus, ce qui est lent ca n'est pas l'algorithme de hash, c'est la lecture des données sur le disque.
Par exemple, avec un Core i5 si je ne lit pas les données depuis le disque je peux hasher 3 GB en 47 secondes avec un seul core.
La même chose en MD5 me donne 3 GB hashé en 24 secondes. Ok, le SHA-512 en deux fois plus lent mais je ne pense pas que ca soit l'algo de hash qui ralentisse le plus dans le cas de Fim. C'est le disque.
En conclusion, j'ai choisi SHA-512 pour la longueur de sa clé (512 bits) qui permet de diminuer les chances de collision quand on hash des fichiers énormes.
Pourquoi historiser tous les changements (fim log) ?
C'est pour pouvoir retrouver ce que l'on a fait comme différentes modifications pour arriver dans cet état.
On n'a pas les anciens contenus et on ne peut pas comparer, mais on a pour chaque révision le commentaire de commit et un résumé des modifications qui ont été apportées.
Le fait de conserver les State entiers permet de revenir à l'état d'avant en effaçant simplement le dernier State. Il faudrait que j'ajoute la commande
revertpour faire cela.Si l'historique gêne, on peut l'effacer avec la commande
purge.Est-ce que le hash de 1mb est suffisant ?
En effet, il pourrait suffire. Mais quand on a énormément de fichiers et un très gros volume, le hash de 4kb permet d'avoir un résultat au
diffvraiment très rapide.Actuellement, je n'ai pas assez d'expérience pour savoir lequel des deux est le plus pertinent.
C'est une bonne idée de hasher un 1mb en prenant 3 blocs de 4K disjoints dans un fichier: 1 au début, 1 à la fin et 1 au milieu.
Est-il prévu de traiter à terme des médias en tenant compte de leur type ?
Je n'ai rien prévu de tel. Mais en effet Fim pourrait évoluer avec le temps.
Toute bonne idée est la bien venue et les contributions aussi.