Estructura de control de fuente para el prototipo y la implementación real

¿Cómo deberíamos estructurar un proyecto en control de fuente con prototipo + implementación 'real' de la aplicación?

Trabajamos en un prototipo para un nuevo proyecto y lo almacenamos en control de fuente (Subversion, pero la pregunta debe ser independiente de eso) con la siguiente estructura en nuestro repository principal con todos nuestros proyectos:

 [Nombre del proyecto]/
   el maletero/
     src /
       UIPrototype /
   twigs /
   tags /

Junto con un pasante, trabajamos en el layout de la lógica del dominio, y planeamos comenzar la implementación de la lógica del dominio la semana siguiente.

Hemos pensado en las siguientes posibilidades:

  • un repository completamente separado (el interno tiene pocas semanas de experiencia con control de fuente / Subversion)

  • un proyecto separado en nuestro repository principal

  • una twig (por ejemplo, branches/prototype ) en el proyecto existente para el prototipo y luego utilizar el trunk para la implementación 'real'

¿Qué estructura recomendarías para esta situación?

Después de haber pasado varios años como gerente de SCM para un gran departamento de software con varios progtwigs, mi recomendación sería hacer una sucursal por las siguientes razones:

  1. Si el prototipo no funciona, puedes dejar que la twig muera en ese punto.

  2. Si el prototipo funciona, puedes fusionarlo de nuevo en un tronco para desarrollo primario

  3. Puede continuar trabajando en el prototipo si las obras en el proyecto principal deben comenzar

Subversion es adecuada para manejar todos estos escenarios. También puede usar tags para ayudar a controlar su código también. Estos deben ser descriptivos como sea posible para que cualquier persona que venga después pueda determinar fácilmente para qué es el código.

Lo que hacemos es tener un repository separado llamado prototypes donde colocamos todos nuestros proyectos de testing / reproducción / experimento / prototipo. Si algo vale la pena, lo movemos a su propio repository.

Tenemos un tree de aplicaciones, y hay directorys labeldos como "internos" que indican cosas que no están destinadas a ser enviadas. Tanto los prototypes como las herramientas internas se pueden desarrollar de esta manera. Además, el código del prototipo siempre es útil para reference cuando comenzamos un proyecto en vivo de próxima generación basado en nuestro aprendizaje del prototipo.