En réponse à la question de gael75 sur obliterate, j'ai fait un peu de recherche pour me mettre à jour sur "oùsque ca en est".
Déjà, un peu de fond sur le problème: Subversion a été conçu avec comme principe premier la protection des données à tout prix. Cela se répercute directement dans l'API, et en particulier dans celle qui implémente le "Système de fichiers versionné", le coeur de Subversion.
En effet, si on consulte cette API, on se rend compte qu'elle ne permet pas du tout d'ouvrir et altérer des données qui ont déjà été commitées. Le seul moyen d'éditer un fichier, c'est démarrer un nouveau commit avant d'éditer, auquel cas toutes les modifications se font dans la transaction en préparation, qui est le seul endroit dans Subversion ou les données sont altérables. Donc, au niveau de toute la conception de Subversion, tout ce qui a été committé un jour est par définition immutable.
Ce qui pose un problème très épineux pour obliterate. Là, on nous demande de programmer une commande qui viole quasiment tous les principes de conception de subversion : Il faut altérer des révisions passées (censées être immutables), voire même modifier toute une ligne d'historique pour faire disparaitre un fichier et l'ensemble de ses modifications. Non-seulement nous sommes réticents à le faire sur le principe (c'est mal de donner aux gens de quoi se tirer une balle dans le pied), mais en plus nous serons obligés de contourner notre API pour le faire, parce qu'elle refusera catégoriquement de toucher à ce qui est immutable.
Ensuite, en ce qui concerne la solution que tu proposes (remplacer le fichier par un fichier vide), elle a été réfléchie, en effet. Mais l'inquiétude réside dans le fait que nous avons deux volontés différentes pour la fonction de cette commande : certains veulent simplement une commande "anti-disque-plein", qui serait adéquatement implémentée par le remplacement par le vide. Mais d'autres (et la très légère majorité je crois) veulent que l'effacement soit "juridiquement correct", c'est à dire qu'il n'y aie aucune trace de l'existence même du fichier. Dans ce cas là, il y a besoin de faire un effacement, un vrai.
Il y a aussi des volontés différentes par rapport à ce que obliterate devrait effectivement détruire : une révision? Un fichier et toute son histoire? Une seule révision d'un certain fichier? Le consensus semble être d'implémenter la suppression d'une révision précise d'un fichier précis, puisque toute autre opération peut se construire par dessus. Mais cela pose d'autres problèmes: s'il y a un historique après la révision, il faudrait re-deltifier le dépot, pour conserver son intégrité. Faut-il re-deltifier en effaçant l'existence du morceau supprimé (cas effacement juridique), ou re-deltifier en fusionnant le morceau effacé avec des révisions futures (Le cas "effacement pour gagner de l'espace disque) ?
Problème épineux donc, au niveau de sa conception de haut niveau (que doit effectivement faire 'svnadmin obliterate' ?), au niveau de l'acceptation (pas mal de développeurs ne sont pas favorables au principe ministère-de-la-Vérité d'obliterate. Cela n'empêchera pas son développement, mais réduit le nombre de développeurs prêts à bosser dessus). Mais de loin le plus gros problème que nous aurons à résoudre, c'est qu'en l'état actuel, notre API ne nous permet matériellement pas d'implémenter obliterate, et que nous ne voulons pas rendre disponible dans l'API publique un svn_fs_obliterate() aux conséquences on ne peut plus irréversibles.
Bref, nous n'avons pas oublié la doléance : c'est le bug #516 de Subversion, un vétéran, et il nous concerne toujours. Mais nous travaillons sur des choses plus importantes à nos yeux (récemment, et en vue de svn 1.4 : un nouveau système de stockage de deltas, avec un gain d'espace disque coté serveur avoisinant les 20%, et de nombreuses optimisations de la vitesse de traitement dans la bibliothèque de gestion de copie de travail), et n'avons simplement actuellement pas de temps alloué à ce problème.
Bien sur, si quelqu'un est motivé, les contributeurs sont les bienvenus! ;-)
[^] # Re: Bravo mais...
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 10.
Déjà, un peu de fond sur le problème: Subversion a été conçu avec comme principe premier la protection des données à tout prix. Cela se répercute directement dans l'API, et en particulier dans celle qui implémente le "Système de fichiers versionné", le coeur de Subversion.
En effet, si on consulte cette API, on se rend compte qu'elle ne permet pas du tout d'ouvrir et altérer des données qui ont déjà été commitées. Le seul moyen d'éditer un fichier, c'est démarrer un nouveau commit avant d'éditer, auquel cas toutes les modifications se font dans la transaction en préparation, qui est le seul endroit dans Subversion ou les données sont altérables. Donc, au niveau de toute la conception de Subversion, tout ce qui a été committé un jour est par définition immutable.
Ce qui pose un problème très épineux pour obliterate. Là, on nous demande de programmer une commande qui viole quasiment tous les principes de conception de subversion : Il faut altérer des révisions passées (censées être immutables), voire même modifier toute une ligne d'historique pour faire disparaitre un fichier et l'ensemble de ses modifications. Non-seulement nous sommes réticents à le faire sur le principe (c'est mal de donner aux gens de quoi se tirer une balle dans le pied), mais en plus nous serons obligés de contourner notre API pour le faire, parce qu'elle refusera catégoriquement de toucher à ce qui est immutable.
Ensuite, en ce qui concerne la solution que tu proposes (remplacer le fichier par un fichier vide), elle a été réfléchie, en effet. Mais l'inquiétude réside dans le fait que nous avons deux volontés différentes pour la fonction de cette commande : certains veulent simplement une commande "anti-disque-plein", qui serait adéquatement implémentée par le remplacement par le vide. Mais d'autres (et la très légère majorité je crois) veulent que l'effacement soit "juridiquement correct", c'est à dire qu'il n'y aie aucune trace de l'existence même du fichier. Dans ce cas là, il y a besoin de faire un effacement, un vrai.
Il y a aussi des volontés différentes par rapport à ce que obliterate devrait effectivement détruire : une révision? Un fichier et toute son histoire? Une seule révision d'un certain fichier? Le consensus semble être d'implémenter la suppression d'une révision précise d'un fichier précis, puisque toute autre opération peut se construire par dessus. Mais cela pose d'autres problèmes: s'il y a un historique après la révision, il faudrait re-deltifier le dépot, pour conserver son intégrité. Faut-il re-deltifier en effaçant l'existence du morceau supprimé (cas effacement juridique), ou re-deltifier en fusionnant le morceau effacé avec des révisions futures (Le cas "effacement pour gagner de l'espace disque) ?
Problème épineux donc, au niveau de sa conception de haut niveau (que doit effectivement faire 'svnadmin obliterate' ?), au niveau de l'acceptation (pas mal de développeurs ne sont pas favorables au principe ministère-de-la-Vérité d'obliterate. Cela n'empêchera pas son développement, mais réduit le nombre de développeurs prêts à bosser dessus). Mais de loin le plus gros problème que nous aurons à résoudre, c'est qu'en l'état actuel, notre API ne nous permet matériellement pas d'implémenter obliterate, et que nous ne voulons pas rendre disponible dans l'API publique un svn_fs_obliterate() aux conséquences on ne peut plus irréversibles.
Bref, nous n'avons pas oublié la doléance : c'est le bug #516 de Subversion, un vétéran, et il nous concerne toujours. Mais nous travaillons sur des choses plus importantes à nos yeux (récemment, et en vue de svn 1.4 : un nouveau système de stockage de deltas, avec un gain d'espace disque coté serveur avoisinant les 20%, et de nombreuses optimisations de la vitesse de traitement dans la bibliothèque de gestion de copie de travail), et n'avons simplement actuellement pas de temps alloué à ce problème.
Bien sur, si quelqu'un est motivé, les contributeurs sont les bienvenus! ;-)