Discussion :

[dev RC0]

Bonjour à tous,

Pour les besoins du projet sur lequel je travaille actuellement, je dois "checkouter" assez régulièrement un projet Java placé sur un dépôt CVS.

Cependant, le projet Java à récupérer est physiquement distant et non accessible par le réseau. Nous avons donc pour cela un disque dur externe exclusivement dédié et configuré pour ce projet que nous donnons régulièrement au service concerné pour qu'il nous fasse une MAJ du projet sur le DD, via un script rsync.ksh. (le serveur CVS est installé sur une RedHat 5).

Nous récupérons ensuite le DD et nous le rebranchons sur un serveur chez nous, également sous RedHat 5. De là on peut faire un checkout ou un update du projet selon le besoin.

Nos postes de développement sont sous Windows 7 pro 64bits.

Le problème est qu'après un checkout, tous les jars et tous les zips inclus dans le projets sont "corrompus" et tout à fait inutilisables.

J'ai aussi tenté de récupérer directement les fichiers concernés depuis le serveur chez nous, histoire de les remplacer "à l'arrache" en local sur le poste de développement. Rien n'y fait, ça ne fonctionne toujours pas.

Je me pose donc la question de savoir si ma configuration d'Eclipse est bonne lors du checkout ? J'ai essayé pas mal d'options mais rien n'y fait...

Quelqu'un aurait-il une idée ou aurait déjà rencontré le problème ?
Est-il possible que le passage de Linux à Windows soit responsable de la corruption des fichiers ?

Merci d'avance pour votre aide.

[Laurent.B]

Bonjour,

Personnellement, je ne vois pas de rapport avec Eclipse dans ce problème.
Il faut d'abord valider toute la chaîne de transmissions des informations avant d'arriver à incriminer Eclipse. En l'occurrence, les données peuvent être corrompues à différents moments, au départ, sur votre serveur RH, par le disque, par le passage de Linux à Windows, par le protocole employé et pourquoi pas, les données pourrait avoir été cryptées par erreur...

Pour être certain qu'Eclipse n'y est pour rien, il suffit d'utiliser un client CVS externe à Eclipse...

Tu ne dis pas clairement si la manipulation que tu décris a déjà fonctionné auparavant ou avec d'autres projets ?

[joel.drigo]

Salut,

Ces fichiers jar et zip (fichiers binaires) ont-ils bien été marqués avec l'option -kb ?

cvs add -kb fichier.jar pour ajouter le fichier ou cvs admin -kb fichier.jar pour marquer un fichier déjà ajouté sans l'option.

[dev RC0]

Merci pour vos messages,

Je cherchais justement de nouvelles pistes.

Je n'incrimine pas Eclipse, je me demandais juste s'il y avait des configurations particulières dedans que je n'aurais pas faites.

Donc pour vous répondre:

Laurent,
Oui, il semble qu'il y ait déjà eu des soucis avec la récupération, mais il n'y a plus personne d"historiquement" présent à cette époque. La seule procédure que j'ai trouvée chez nous étant celle qui explique qu'il y a un script rsync.ksh à exécuter, ce qui est fait.
Tu me mets la puce à l'oreille avec le cryptage... Il est bien possible qu'il y ait un souci à ce niveau. Je vais vérifier auprès du service concerné.

Joël, je ne sais pas si l'option -kb est posée. Là aussi je vais leur demander.

Je reviens vers vous avec de nouvelles réponses dès que possible.

Merci à tous les deux.

[dev RC0]

Re-bonjour

Donc aucune des hypothèses levées dans la discussion n'a abouti pour le moment.
Nous avons toujours des problèmes sur la synchro CVS avec les fichiers zips et jars.

La solution trouvée pour le moment, dans un souci de temps, est d'aller directement récupérer le projet Eclipse sur le poste des collègues là-bas....
Du coup, plus aucun problèmes de fichiers corrompus et illisibles.

C'est un peu nul mais bon, il faut bien avancer..

Merci pour vos réponses, cela a permit d'explorer de nouvelles pistes.

Bonne journée à tous.