estructura de control de fuente de prototipo y implementación real

Question

¿Cómo debemos estructurar un proyecto de control de código fuente con el prototipo + aplicación 'real' de la aplicación?

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

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

Junto con un interno, trabajamos en el diseño de la lógica de dominio, y tenemos la intención de iniciar la ejecución de la lógica de dominio en la semana siguiente.

Hemos pensado en las siguientes posibilidades:

• un repositorio completamente separado (el interno tiene pocas semanas de experiencia en control de código fuente / Subversion)

• un proyecto separado en nuestro repositorio principal

• una rama (por ejemplo branches/prototype) en el marco del proyecto existente para el prototipo y luego usar trunk para la aplicación 'real'

¿Qué estructura me recomiendan para esta situación?

Answer 1

Después de haber pasado varios años como gerente de SMC para un departamento de software grande con varios programas, mi recomendación sería hacer una rama por las siguientes razones:

1. Si el modelo no funciona se puede dejar morir la rama en ese punto.

2. Si el modelo funciona, entonces se puede combinar de nuevo en un tronco principal para el desarrollo

3. Se puede seguir trabajando en el prototipo si obras del proyecto principal debe comenzar

Subversion es muy adecuado para manejar todos estos escenarios. También puede utilizar las etiquetas para ayudar a controlar su código. Estos deben ser más descriptivo posible para que cualquier persona que viene después es fácil determinar cuál es el código para.

Answer 2

Lo que hacemos es tener un repositorio separado llamado prototipos donde ponemos todos nuestros proyectos de prueba / juego / experimento / prototipo. Si hay algo que vale la pena, lo movemos a su propio repositorio.

Answer 3

Tenemos un árbol de aplicaciones, y hay directorios etiquetados 'Resto' que indican cosas no destinados para su envío. Ambos prototipos y herramientas internas se pueden desarrollar de esta manera. Además, el código prototipo está siempre a mano para consultarlo cuando comenzamos una nueva generación de proyectos 'en vivo' sobre la base de nuestro aprendizaje a partir del prototipo.