Je rajoute mon petit^Wtrès gros grain de sel à la discussion sur Subversion.
Le gros du problème entre Subversion et BDB est blocage de la base BDB en cas d'arrêt violent du traitement d'une requête par le serveur svn. Cela arrive relativement souvent quand on utilise mod_dav_svn, ou toute interface web maniant le dépôt et pouvant être interrompue violemment. Le problème, c'est que le dévérouillage (et l'éventuelle réparation) ne peut pas se faire automatiquement par l'application cliente (Subversion) sans risques de corruption, sauf si on peut lui garantir un accès exclusif à la base pendant la réparation. Donc, le dépot reste vérouillé jusqu'a ce qu'un d'admin coupe tous les moyens d'accès au dépot et exécute `svnadmin recover` dessus (qui lui par dessous dit à BDB qu'il peut réparer tranquillement).
Cette situation a été discutée avec SleepyCat Software. Ils ont demandé aux développeurs de Subversion ce qu'ils aimeraient avoir dans les prochaines versions de BDB, et la réponse fut massive: "Database auto-recovery", c'est à dire le dévérouillage et la réparation automatique et sans risques dans un environnement où l'accès est non-exclusif (lire: en prod).
Et c'est chose faite. Comme l'indique la liste des nouvelles fonctionalités ci-dessus, BDB 4.4 ferme plusieurs tickets internes traitant de cette réparation automatique en-ligne. Avec BDB 4.4, Subversion n'aura plus qu'a ouvrir le dépot normalement, et la bibliothèque BDB effectuera automatiquement l'équivalent de `svnadmin recover` avant d'ouvrir la base. BDB revient donc à égalité à FSFS (l'autre système de stockage de dépot de Subversion) : dans les deux, une mort violente de Subversion n'entraine que quelques fichiers de verrou et de journal qui trainent dans le dépot, et qui seront nettoyés à l'ouverture suivante de celui-ci.
BDB 4.4 venant de sortir, il faudra patienter au moins jusqu'a Subversion 1.4 (la 1.3 est en Release Candidate en ce moment) pour avoir le support BDB 4.4. Et pour répondre à la question d'origine, il faudra sans doute faire un dump/load pour mettre à jour un dépot Subversion BDB, lorsque le support BDB 4.4 apparaitra. Le changement dans la structure interne de BDB est qualitativement similaire à celui qui a eu lieu entre BDB 4.2 et BDB 4.3 .
Enfin, une petite note par rapport au commentaire précédent, qui dit en substance que Subversion va "plus vite" avec un dépot FSFS. Ce n'est pas entièrement vrai. Les données sont stockées très différemment dans un dépot FSFS par rapport à un dépot BDB, et ces différences font que parfois c'est l'un qui est meilleur, et parfois c'est l'autre.
Par exemple, BDB stocke la dernière version entièrement, et exprime les révisions précédentes sous forme de delta, alors que FSFS stocke une révision N en entier et exprime les révisions suivantes sous forme de delta ; un checkout de la dernière version avec BDB sera donc très rapide, alors que FSFS aura besoin de temps et de ressources pour recombiner les deltas à partir de la dernière révision complète.
De même, FSFS est beaucoup plus rapide pendant la construction d'une transaction à commiter dans le dépôt, mais la finalisation (étape ultime du commit ou le serveur construit le fichier de révision et l'insère dans le dépot) prend un temps proportionnel au volume de modifications propagées. Il est donc possible avec FSFS qu'un très gros commit (plusieurs centaines de Mo de diffs) fasse timeouter le client pendant la phase de finalisation. BDB au contraire étale l'impact d'un gros commit sur toutes les phases, autant la construction de la transaction que sa finalisation, et ne souffrira donc pas de ces problèmes.
(Le dernier exemple avec des diffs de plusieurs centaines de Mo peut sembler tirée par les cheveux, mais c'est tiré d'histoires vraies - certaines entreprises gardent des Go d'isos de DVD dans Subversion; les commits de centaines de Mo ne sont pas exceptionnels, quand l'iso est modifiée)
Tout ça pour dire que les deux backends ont leurs avantages et leurs inconvénients respectifs. Il est vrai que BDB, avec son problème de verrous, a une mauvaise image auprès des utilisateurs. Mais s'il est encore distribué avec Subversion, c'est bien parce qu'il peut etre meilleur que FSFS dans certains cas - et l'ajout de réparation automatique ne fera que le rendre plus attractif à mon humble avis. Je vous recommande vivement la lecture du Subversion Book, sur http://www.svnbook.org/ . Le début du chapitre 5 compare les deux solutions, et discute des avantages et inconvénients respectifs.
Voila voila, fin de la réponse de barbare. Bravo si vous lisez encore :-)
[^] # Re: Et les mise à jours de bases?
Posté par David Anderson . En réponse à la dépêche Sortie de Berkeley DB 4.4. Évalué à 10.
Le gros du problème entre Subversion et BDB est blocage de la base BDB en cas d'arrêt violent du traitement d'une requête par le serveur svn. Cela arrive relativement souvent quand on utilise mod_dav_svn, ou toute interface web maniant le dépôt et pouvant être interrompue violemment. Le problème, c'est que le dévérouillage (et l'éventuelle réparation) ne peut pas se faire automatiquement par l'application cliente (Subversion) sans risques de corruption, sauf si on peut lui garantir un accès exclusif à la base pendant la réparation. Donc, le dépot reste vérouillé jusqu'a ce qu'un d'admin coupe tous les moyens d'accès au dépot et exécute `svnadmin recover` dessus (qui lui par dessous dit à BDB qu'il peut réparer tranquillement).
Cette situation a été discutée avec SleepyCat Software. Ils ont demandé aux développeurs de Subversion ce qu'ils aimeraient avoir dans les prochaines versions de BDB, et la réponse fut massive: "Database auto-recovery", c'est à dire le dévérouillage et la réparation automatique et sans risques dans un environnement où l'accès est non-exclusif (lire: en prod).
Et c'est chose faite. Comme l'indique la liste des nouvelles fonctionalités ci-dessus, BDB 4.4 ferme plusieurs tickets internes traitant de cette réparation automatique en-ligne. Avec BDB 4.4, Subversion n'aura plus qu'a ouvrir le dépot normalement, et la bibliothèque BDB effectuera automatiquement l'équivalent de `svnadmin recover` avant d'ouvrir la base. BDB revient donc à égalité à FSFS (l'autre système de stockage de dépot de Subversion) : dans les deux, une mort violente de Subversion n'entraine que quelques fichiers de verrou et de journal qui trainent dans le dépot, et qui seront nettoyés à l'ouverture suivante de celui-ci.
BDB 4.4 venant de sortir, il faudra patienter au moins jusqu'a Subversion 1.4 (la 1.3 est en Release Candidate en ce moment) pour avoir le support BDB 4.4. Et pour répondre à la question d'origine, il faudra sans doute faire un dump/load pour mettre à jour un dépot Subversion BDB, lorsque le support BDB 4.4 apparaitra. Le changement dans la structure interne de BDB est qualitativement similaire à celui qui a eu lieu entre BDB 4.2 et BDB 4.3 .
Enfin, une petite note par rapport au commentaire précédent, qui dit en substance que Subversion va "plus vite" avec un dépot FSFS. Ce n'est pas entièrement vrai. Les données sont stockées très différemment dans un dépot FSFS par rapport à un dépot BDB, et ces différences font que parfois c'est l'un qui est meilleur, et parfois c'est l'autre.
Par exemple, BDB stocke la dernière version entièrement, et exprime les révisions précédentes sous forme de delta, alors que FSFS stocke une révision N en entier et exprime les révisions suivantes sous forme de delta ; un checkout de la dernière version avec BDB sera donc très rapide, alors que FSFS aura besoin de temps et de ressources pour recombiner les deltas à partir de la dernière révision complète.
De même, FSFS est beaucoup plus rapide pendant la construction d'une transaction à commiter dans le dépôt, mais la finalisation (étape ultime du commit ou le serveur construit le fichier de révision et l'insère dans le dépot) prend un temps proportionnel au volume de modifications propagées. Il est donc possible avec FSFS qu'un très gros commit (plusieurs centaines de Mo de diffs) fasse timeouter le client pendant la phase de finalisation. BDB au contraire étale l'impact d'un gros commit sur toutes les phases, autant la construction de la transaction que sa finalisation, et ne souffrira donc pas de ces problèmes.
(Le dernier exemple avec des diffs de plusieurs centaines de Mo peut sembler tirée par les cheveux, mais c'est tiré d'histoires vraies - certaines entreprises gardent des Go d'isos de DVD dans Subversion; les commits de centaines de Mo ne sont pas exceptionnels, quand l'iso est modifiée)
Tout ça pour dire que les deux backends ont leurs avantages et leurs inconvénients respectifs. Il est vrai que BDB, avec son problème de verrous, a une mauvaise image auprès des utilisateurs. Mais s'il est encore distribué avec Subversion, c'est bien parce qu'il peut etre meilleur que FSFS dans certains cas - et l'ajout de réparation automatique ne fera que le rendre plus attractif à mon humble avis. Je vous recommande vivement la lecture du Subversion Book, sur http://www.svnbook.org/ . Le début du chapitre 5 compare les deux solutions, et discute des avantages et inconvénients respectifs.
Voila voila, fin de la réponse de barbare. Bravo si vous lisez encore :-)