En effet, et c'est même une question posée par rapport au stockage de documents OpenOffice.org dans Subversion qui a amené la question de la façon de procéder. Comme dit ailleurs dans ces commentaires, les modules de diff spécialisés selon les types mime sont sur la feuille de route à long terme, mais pas prévu pour dans l'immédiat.
Le résultat, c'est qu'après une demi-douzaine de hacks proposés pour supporter explicitement le format OOo, il a été proposé autre chose, plus simple et offrant un gain pour plus de monde.
Debian a intégré à sa libz un patch ajoutant une option pour produire des fichiers compressés "rsyncable", c'est à dire ayant une empreinte changeante minimale, pour faciliter les rsync rapides. Il a été suggéré à OOo qu'ils intègrent cette modification algorithmique (qui devrait etre portable aux algos zip), ainsi les deltas entre deux versions d'un fichier se verraient grandement réduits. En le faisant à ce niveau là, le gain n'est pas seulement pour les utilisateurs de Subversion, mais pour la totalité des applications qui se causent en diffs.
Je comprends que cette solution puisse sembler être un passage de la patate chaude, mais il faut aussi voir le contexte : dans le cadre de la discussion sur "est-ce qu'il faudrait traiter les fichiers compressés spécialement?", il y a eu énormément de tentatives de pousser les développeurs à introduire un système similaire à Clearcase, ou tous les fichiers sont spéciaux et gérés différemment. Ca s'est terminé en un affront du type "soit on implémente la spécialisation des diffs maintenant, pour tout, soit on fait rien et on attend de pouvoir le faire correctement". C'est ce dernier, en combinaison avec une suggestion au projet OOo, qui a été retenue, et ce au moins jusqu'a ce que le merge tracking soit implémenté.
Donc, euh, voila. Donc l'état actuel, c'est que les fichiers compressés sont traités comme tous les autres (notez tout de même que c'est toujours mieux que CVS, puisqu'il y a un algo de diff binaire assez efficace), ce qui place Subversion à égalité avec beaucoup d'outils concurrents (à l'exception notable des plus gros, plus anciens et plus commerciaux). Et l'état futur, c'est que c'est l'une des montagnes à l'horizon que nous franchirons sur notre chemin :-)
[^] # Re: Felicitations a ttes l'équipe !
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 5.
Le résultat, c'est qu'après une demi-douzaine de hacks proposés pour supporter explicitement le format OOo, il a été proposé autre chose, plus simple et offrant un gain pour plus de monde.
Debian a intégré à sa libz un patch ajoutant une option pour produire des fichiers compressés "rsyncable", c'est à dire ayant une empreinte changeante minimale, pour faciliter les rsync rapides. Il a été suggéré à OOo qu'ils intègrent cette modification algorithmique (qui devrait etre portable aux algos zip), ainsi les deltas entre deux versions d'un fichier se verraient grandement réduits. En le faisant à ce niveau là, le gain n'est pas seulement pour les utilisateurs de Subversion, mais pour la totalité des applications qui se causent en diffs.
Je comprends que cette solution puisse sembler être un passage de la patate chaude, mais il faut aussi voir le contexte : dans le cadre de la discussion sur "est-ce qu'il faudrait traiter les fichiers compressés spécialement?", il y a eu énormément de tentatives de pousser les développeurs à introduire un système similaire à Clearcase, ou tous les fichiers sont spéciaux et gérés différemment. Ca s'est terminé en un affront du type "soit on implémente la spécialisation des diffs maintenant, pour tout, soit on fait rien et on attend de pouvoir le faire correctement". C'est ce dernier, en combinaison avec une suggestion au projet OOo, qui a été retenue, et ce au moins jusqu'a ce que le merge tracking soit implémenté.
Donc, euh, voila. Donc l'état actuel, c'est que les fichiers compressés sont traités comme tous les autres (notez tout de même que c'est toujours mieux que CVS, puisqu'il y a un algo de diff binaire assez efficace), ce qui place Subversion à égalité avec beaucoup d'outils concurrents (à l'exception notable des plus gros, plus anciens et plus commerciaux). Et l'état futur, c'est que c'est l'une des montagnes à l'horizon que nous franchirons sur notre chemin :-)