Comment ajouter les pages de fitnesse au contrôle de version ?

Question

Quelle est la pratique recommandée ? Dois-je ajouter le sous-dossier my sous le dossier fitnesse au contrôle de version ?

Contexte : je travaille sur un projet rails pour un seul développeur. Mon projet rails est sous contrôle de version (Subversion) mais mes pages wiki fitnesse se trouvent dans le dossier fitnesse program.

Fitnesse semble avoir son propre contrôle de version... (Je vois des zips numérotés avec chacune de mes pages wiki) Est-il fiable ? Où stocke-t-il les révisions ?

Answer 1

Utilisez le -d interrupteur ( qui est étonnamment peu visible lors d'une recherche sur Google. )

Fitnesse20081201>run -p 8080 -d c:/projects/MyProjectNeedsAcceptanceTests

Cela créera un sous-dossier dans le dossier spécifié appelé FitnesseRoot s'il n'existe pas déjà, avec tout ce dont il a besoin pour fonctionner.

Fitnesse devrait être en place. Passez à votre navigateur. Allez-y et créez vos pages.

• Vous aurez un sous-dossier pour chaque page Fitnesse que vous créerez.
• Chaque dossier aurait un content.txt (qui est le contenu du wiki) et un properties.xml (qui sont les propriétés de Fitnesse pour cette page).
• Toutes les sous-pages seraient des sous-dossiers sous le dossier de la page parent.

Répertoires et fichiers... Vous êtes prêt pour votre premier enregistrement dans le contrôle de version. Configurez également votre contrôle de version pour ignorer certains types de fichiers.

• FitnesseRoot/files
• FitnesseRoot/ErrorLog
• *.zip

(Les fichiers .zip sont la façon dont Fitnesse garde la trace des modifications apportées aux pages du wiki un contrôle de version local à court terme. Les VCS comme svn, git, cvs, etc. devraient s'en charger pour nous. Nous n'avons donc pas besoin de vérifier les fichiers zip).

J'espère que ça a du sens Si ce n'est pas le cas, je vous suggère de prendre 15 minutes pour écouter le screencast suivant d'OncleBob lui-même.
Source : Robert Martin - Contrôle de version et environnement de développement pour Fitnesse

Answer 2

Si vous utilisez le contrôle de version avec Fitnesse, vous n'aurez pas besoin de l'archive zip pour chaque révision. Utilisez l'option -e 0 pour empêcher la création des archives zip :

java -jar fitnesse.jar -p 8001 -e 0

Answer 3

FitNesse stocke les anciennes révisions de chaque page dans un fichier zip dans le même répertoire que les fichiers de la page. Le nom du fichier zip marque l'horodatage de la révision. Son fonctionnement est similaire à celui de wikipedia - historique, mais pas de contrôle de version à part entière.

Dans notre entreprise, nous voulions une configuration où chaque fois que nous vérifions une révision (éventuellement ancienne) de la source, nous vérifions également les tests FitNesse qui passent pour cette version spécifique.

Par conséquent, nous avons installé FitNesse (le répertoire fitnesse, y compris l'exécutable FitNesse et le répertoire FitNesseRoot) à l'intérieur de notre arbre source dans le contrôle de version, en établissant une règle pour ne pas importer les *.zip à l'intérieur du répertoire FitNesseRoot (car nous avons le contrôle de version pour garder l'historique pour nous et n'en avons pas besoin).

Cela fonctionne parfaitement avec des SCMs sains (j'ai utilisé svn avec svn-tortoise).

Lorsque nous sommes passés au contrôle de source Microsoft Foundation Server, nous avons rencontré de nombreux problèmes avec le flux de travail checkout-edit-checkin. Encore une fois, ce flux de travail est simplement une mauvaise idée en général, et ne devrait être utilisé que par les fous du contrôle.

(modification : réponse à la question du commentateur)

Answer 4

Depuis la version 20090214 de Fitnesse, l'intégration de CM est incluse, voir le guide d'utilisation pour plus de détails. http://fitnesse.org/FitNesse.UserGuide.SourceCodeControl

Le plugin git hub est inclus dans la distribution fitnesse.

Je vois un plug-in pour perforce à http://code.google.com/p/perforcecmsystem/ mais je ne l'ai pas encore mis en place pour mon équipe.