structure de contrôle de la source pour le prototype et la mise en œuvre réelle

Question

Comment devrions-nous structurer un projet dans le contrôle de la source avec la mise en œuvre du prototype + « réel » de l'application?

Nous travaillons sur un prototype d'un nouveau projet et stocker que dans le contrôle de source (Subversion, mais la question doit être indépendante de celle) avec la structure suivante dans notre référentiel principal avec tous nos projets:

[ProjectName]/
  trunk/
    src/
      UIPrototype/
  branches/
  tags/

En plus d'un stagiaire, nous travaillons sur la conception de la logique de domaine, et nous prévoyons de commencer la mise en œuvre de la logique de domaine dans la semaine suivante.

Nous avons réfléchi sur les possibilités suivantes:

• un référentiel complètement séparé (le stagiaire a quelques semaines d'expérience avec le contrôle de la source / Subversion)

• un projet distinct dans notre dépôt principal

• une branche (par exemple branches/prototype) dans le cadre du projet existant pour le prototype et utiliser ensuite trunk pour la mise en œuvre 'réel'

Quelle est la structure recommanderiez-vous cette situation?

Answer 1

Après avoir passé plusieurs années en tant que responsable de SCM pour un grand service logiciel avec plusieurs programmes, ma recommandation serait de faire une branche pour les raisons suivantes:

1. Si le prototype ne fonctionne pas, vous pouvez laisser mourir de branche à ce moment-là.

2. Si le prototype fonctionne, vous pouvez ensuite fusionner de nouveau dans un tronc pour le développement primaire

3. Vous pouvez continuer à travailler sur le prototype si les travaux sur le projet primaire doit commencer

Subversion est bien adapté pour gérer tous ces scénarios. Vous pouvez également utiliser des étiquettes pour aider à contrôler votre code. Ceux-ci devraient être descriptif que possible afin que toute personne qui vient après vous pouvez facilement déterminer ce que le code est pour.

Answer 2

Ce que nous faisons est d'avoir un dépôt séparé appelé prototypes où nous avons mis tous nos tests / jeu / expérience / projets de prototypes. Si quelque chose vaut la peine, on passe à son propre référentiel.

Answer 3

Nous avons un arbre d'application, et il y a des répertoires étiquetés « inhouse » qui indiquent les choses ne sont pas destinés à l'expédition. Les deux prototypes et outils internes peuvent être développés de cette manière. De plus, le code prototype est toujours à portée de main pour référence lorsque nous commençons un projet de nouvelle génération « live » basé sur notre apprentissage du prototype.