Quelques fois déjà, je me suis retrouvé dans des situations où un de mes référentiels SVN était corrompu et nous pouvions faire n'importe quoi avec certaines versions ou branches du projet sans vraiment savoir ce que nous faisions. Donc, je demande ce qui peut causer un référentiel à devenir corrompu? Il semble que les incompatibilités entre les clients peuvent causer des problèmes, plus particulièrement avec les jeux de caractères.Comment un référentiel SVN peut-il être corrompu?
Répondre
Il existe essentiellement trois cas distincts:
- matériel défectueux (mémoire, fs corruption, etc.)
- de l'utilisateur avec l'accès de connexion au serveur peut fichiers du référentiel corrompus.
- Bogues dans Subversion.
Le matériel défectueux est généralement le plus difficile à repérer, sauf dans les cas les plus évidents. Le cas 2 est évitable en limitant l'accès de connexion au serveur. Tout le reste est un bug dans Subversion. (Cela inclut les problèmes de compatibilité entre le client et le serveur.) ne peut jamais corrompre le référentiel en utilisant simplement un client Subversion (même s'il y a un bogue dans le client, IMO).
Je serais très surpris de voir un tel bug dans Subversion. Il est développé dans le but de ne pas perdre une donnée en raison d'un bug dans une version finale. – Hardcoded
Je serais très surpris s'il n'y avait pas un tel bug dans Subversion, tapi dans un coin sombre. Chaque logiciel a un certain nombre de bogues potentiellement très sérieux, la question est de savoir dans quelles circonstances il se manifestera. – JesperE
Corruption potentielle du système de fichiers ou quelqu'un qui dérape avec les répertoires svn internes?
Je l'ai eu plusieurs fois. SVN ne semble pas bien se débrouiller si le client s'en va alors que le serveur met du temps à faire certaines choses. Je ne connais pas les détails exacts, mais j'ai fait quelques kill -9
s sur ce que je pensais être des processus en lecture seule et j'ai fini par devoir exécuter un svnadmin cleanup
par la suite avant que le serveur ne réponde à nouveau.
Il n'y a pas de processus en lecture seule dans svn; il crée toujours une transaction, même pour la mise à jour. Voir http://svnbook.red-bean.com/fr/1.0/ch05.html#svn-ch-5-sect-1.1 pour les détails. – CesarB
svnadmin n'a pas de commande de nettoyage. svn cleanup est une commande clientide. Dans tous les cas, sauf l'accès au fichier: /// repository, un client crash/hang ne peut jamais endommager le serveur ou les données.Et file: /// l'accès sur le réseau n'est certainement pas recommandé. –
@Bert: Oups, je voulais dire svnadmin récupérer. – flussence
Ceci est assez commun sur les repos basés sur file://
, mais si vous avez un seul utilisateur/service accédant au repo, cela n'arrivera pas.
Il est toujours possible que le matériel soit défectueux. Des choses comme des erreurs de bits dans la mémoire peuvent provoquer une corruption silencieuse au lieu de simplement écraser l'ordinateur; Si un processus serveur svn est celui affecté, le référentiel peut être corrompu.
J'ai eu une corruption repo qui m'a pris un moment pour comprendre. Sur le serveur j'avais accidentellement changé le propriétaire du répertoire .svn dans le repo à un utilisateur non lié. SVN m'a donné des erreurs de corruption après cela jusqu'à ce que j'ai supprimé et recréé le repo. Même après que je l'ai corrigé. claques front
Si les dépôts ne sont pas sur les serveurs svn disque local, mais sur NFS, ils peuvent être endommagés s'ils utilisent le format Berkley db. Dans svn 1.5 FSFS est devenu la valeur par défaut pour les nouveaux repos - il est parfaitement heureux de vivre sur des systèmes de fichiers non verrouillables, comme NFS.
Vous n'utilisez pas l'accès à un fichier: /// sur un réseau, ou êtes-vous? –
Quel système d'exploitation/version? –
Nous sommes dans un environnement très hétérogène. – Loki