Puis-je avoir svn pour les scripts RFT? Nous

Question

utilisateur svn au travail et maintenant nous présentons RFT (de Rational Functional Tester).

Y at-il une chance que je peux utiliser svn pour mettre à jour mes scripts RFT? J'ai compris qu'un script RFT contient n'est pas égal à un seul fichier.

• v 8.1.1.2 RFT fonctionne sur Windows XP
• svn fonctionne sur Linux

---

• est-il assez bon pour la version .class et .java fichiers?

Answer 1

Vous pouvez utiliser Subversion pour mettre à jour n'importe quel fichier. Cependant, les fichiers texte et binaires sont traités différemment. Pour les fichiers texte, il est possible d'afficher les différences ligne par ligne, avec les fichiers binaires, vous pouvez simplement consulter une version plus ancienne.

Answer 2

Installez VMware Ubuntu sur les boîtes de développeur Windows XP et exécutez Linux sur celui-ci. C'est exactement ce que nous avons fait dans notre organisation précédente. Tous les développeurs ont installé VMware Ubuntu sur nos machines Windows. Vous pouvez utiliser Eclipse ou MyEclipse ou RFT à partir de là, la version du code RFT à partir de l'IDE ou à partir de l'invite de commande.

Answer 3

Nous avons été succcessful en utilisant RFT avec SVN. Cependant, nous avons dû utiliser le verrouillage de fichier car il existe un certain nombre de fichiers (XML) utilisés pour créer un script RFT. Nous avons ajouté le plugin subclipse à RFT. Nous créons ensuite un projet RFT vide portant le même nom que le projet que nous avons importé dans SVN. Nous vérifions ensuite le projet RFT de SVN en plus de (Overwrite) le projet RFT vide. Lorsque nous créons un nouveau script, nous ajoutons la propriété svn: needs-lock au fichier java. Lorsque nous effectuons des mises à jour et des validations, nous sélectionnons le projet dans les autres fichiers de ressources associés au script à inclure dans le commit.

Answer 4

Oui, vous pouvez utiliser SVN. Mais NE PAS version. Fichiers .class, car ils sont compilés fichiers java et peuvent changer entre les versions. Il est préférable de reconstruire le projet à partir d'Eclipse chaque fois que vous effectuez une mise à jour. Attention, certains fichiers RFT ne peuvent pas être fusionnés (comme datapools .rftdp) car ce sont des fichiers XML écrits sur une seule ligne, donc vous devez verrouiller ces fichiers si vous devez les éditer ou les synchroniser avec votre équipe ou vous pouvez résoudre les conflits en acceptant la dernière révision validée.

Answer 5

Je vais répéter un peu les autres réponses, mais j'espère pouvoir le clarifier davantage.

Premier problème: fichiers Object Map. Ce sont des fichiers XML simples. Ils pourraient facilement être suivis au contrôle de version, malheureusement IBM a fait un gâchis ici. Ils n'utilisent pas une bonne bibliothèque d'analyse pour le XML. Il doit être contenu dans une seule ligne. Si vous tidifiez le code, il ne sera plus analysé. Puisque le logiciel de contrôle de version suit les différences de ligne, chaque changement simple créera un désordre de conflit.

Même si cela fonctionnait après reformatage sur plusieurs lignes, chaque petite modification (par exemple, ajouter un nouvel objet de test) réorganiserait tout le contenu xml. Bien sûr, j'ai tout essayé.

En pratique, les fichiers de mappages d'objets sont des fichiers binaires et vous devez ajouter la propriété svn: lock à chacun d'entre eux.Ils ont utilisé XML comme un mot à la mode, en empêchant intentionnellement tous les avantages de format.

Deuxième problème: RFT génère beaucoup de fichiers d'aide à partir de vos mappes d'objets. Ce sont les fichiers dans le répertoire "resources". Contre les bonnes pratiques de contrôle de version, vous devez également valider manuellement ces fichiers. Soyez prêt à commettre tout ce qui change. RFT possède l'intégration ClearCase, et vérifie et vérifie automatiquement tous les fichiers nécessaires. Mais n'allez pas dans cette intégration de l'enfer. Vous seriez mieux avec Subversion.

Conclusion: Si vous utilisez RFT, vous êtes condamné à avoir un développement séquentiel. Vous ne pouvez pas avoir 2 développeurs travaillant dans la même base de code. Bienvenue dans les années 70!