Erreur VisualSVN - Fichier de révision manque Trailing Newline

Question

Nous avons VisualSVN Server 2.1.3 installé sur Windows Server 2003 et toutes les machines clientes utilisent le client TortoiseSVN pour les validations et autres opérations svn. Tout fonctionnait bien jusqu'à hier.

Hier, j'ai commis un numéro de révision 22181 dans la nuit et j'ai quitté le bureau et c'est le dernier commit qui est arrivé depuis hier. Lorsque j'ai essayé de montrer aujourd'hui journal ou essayé de mettre à jour SVN, je suis arrivé cette erreur:

Revision File Lacks Trailing Newline. 

Puis j'ai commencé des recherches et a essayé beaucoup de choses, y compris le lien ci-dessous qui vient en premier résultat dans google quand je tape la Erreur de description.

http://www.jamesstroud.com/jamess-miscellaneous-how-tos/os-x-admin/fix-svn-revision-file-lacks-trailing-newline

Bien que ce lien indique que cette erreur se produit lorsque svn commit la taille est plus de 4 Go, mais le dernier commit que je l'ai fait était d'à peine 1Mo. Je encore effectué les étapes ci-dessus mentionnées dans le poste et après cela, j'ai pu faire Afficher le journal dans le référentiel qui est un bon signe, mais je suis une autre erreur quand j'ai essayé de commettre un fichier:

Cannot move tempfile.2.tmp to txn-current : the disk structure is corrupted. 

Ensuite, Je suis retourné les changements ci-dessus que j'ai pris la sauvegarde au début et a étudié plus et comme indiqué ci-dessus, il m'a donné une idée que le problème est avec la dernière révision que j'ai commise hier. Ensuite, j'ai essayé svnadmin.exe en utilisant la ligne de commande et la commande dump utilisé pour faire un fichier de vidage entre la révision 1-22180 mais mais étonné de voir que mon serveur a été pendu comme taille de vidage qui était créé était plus que la taille du lecteur où j'étais enregistrer le fichier de vidage. Mon motif derrière le vidage était de vider toutes les révisions sauf la dernière qui est 22181 et ensuite créer un nouveau dépôt et charger le fichier de vidage et cela pourrait résoudre le problème. Et puis j'ai lu que si nous spécifions des révisions spécifiques dans la commande dump, cela prend plus d'espace que le vidage créé de la base de données entière. Mais si prendre le vidage de la base de données entière alors comment puis-je supprimer la dernière révision du fichier de vidage complète?

Si vous voulez savoir, je commande svnadmin couru alors voici: svnadmin.exe dump –r 1-9 F:\svn-repo > C:\Tempdump.dmp

Maintenant, je suis en train d'utiliser vérifier la commande après avoir affiché ce message.

S'il vous plaît aidez-moi à résoudre ce problème car je suis fatigué maintenant et demain notre personnel ne sera pas en mesure de travailler sans svn opérations car il est essentiel. Notre taille de dépôt SVN est de presque 35Go et je pense que si je dois utiliser la commande dump, je devrai attacher un disque dur USB pour enregistrer le fichier de vidage car le disque du serveur qui a un maximum d'espace est de 48Go.

Je ne suis pas sûr de la solution. S'il vous plaît, aidez et merci de tout lire.

Merci

Answer 1

1. Le dépôt est endommagé, avez-vous une sauvegarde à restaurer à partir? La restauration du référentiel à partir de la sauvegarde serait la meilleure solution.

   D'une manière générale, il est logique de courir contre svnadmin verify chaque dépôt que vous avez sur le périphérique de stockage pour le vérifier pour la corruption. Voir svnadmin verify command-line reference.

   Veuillez noter qu'il ressemble à un périphérique de stockage (disque dur?) a été corrompu sur la nuit lorsque vous avez commis la révision 22181, je recommande fortement le vérifiant pour les erreurs en utilisant chkdsk outil et en remplaçant si nécessaire. Voir chkdsk tool reference.

2. Il est prévu que le vidage produit par svnadmin dump (en utilisant les paramètres par défaut ) soit plus grand que le référentiel sur le disque. Si vous souhaitez réduire la taille des révisions 0-22180, utilisez l'option "--deltas".

   Voir SVNBook | Repository data migration using svnadmin:

   By default, the dump file will be quite large—much larger than the repository itself. That's because by default every version of every file is expressed as a full text in the dump file. This is the fastest and simplest behavior, and it's nice if you're piping the dump data directly into some other process (such as a compression program, filtering program, or loading process). But if you're creating a dump file for longer-term storage, you'll likely want to save disk space by using the --deltas option. With this option, successive revisions of files will be output as compressed, binary differences—just as file revisions are stored in a repository. This option is slower, but it results in a dump file much closer in size to the original repository.