estrutura de controle de origem para protótipo e implementação verdadeira

Question

Como devemos estruturar um projeto no controle de origem com o protótipo implementação + 'real' da aplicação?

Eu trabalho em um protótipo para um novo projeto e loja que no controle de origem (Subversion, mas a questão deve ser independente do que) com a seguinte estrutura no nosso repositório principal com todos os nossos projetos:

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

Junto com um estagiário que trabalhar em design para a lógica de domínio, e pretendemos começar a implementação da lógica de domínio na semana seguinte.

Nós temos pensado sobre as seguintes possibilidades:

• um repositório completamente separado (o estagiário tem poucas semanas de experiência com controle de origem / Subversion)

• um projeto separado no nosso repositório principal

• um ramo (por exemplo branches/prototype) no âmbito do projecto existente para o protótipo e, em seguida, usar trunk para a implementação 'real'

Qual a estrutura que você recomendaria para esta situação?

Answer 1

Depois de ter passado vários anos como gerente de SCM para um grande departamento de software com vários programas, a minha recomendação seria fazer um ramo, pelos seguintes motivos:

1. Se o protótipo não funcionar, você pode deixar morrer a filial naquele ponto.

2. Se o protótipo funciona, então você pode mesclar-lo de volta em um tronco para o desenvolvimento primário

3. Você pode continuar a trabalhar no protótipo se trabalhos sobre as necessidades do projeto primários para começar

Subversion é bem adequado para lidar com todos esses cenários. Você também pode usar rótulos para ajudar a controlar o seu código também. Estes devem ser mais descritivo possível para que qualquer pessoa que vem depois você pode facilmente determinar o que o código é para.

Answer 2

O que fazemos é ter um repositório separado chamado protótipos onde colocamos todos os nossos projetos de teste / jogo / experiência / protótipos. Se algo vale a pena, que movê-lo para seu próprio repositório.

Answer 3

Nós temos uma árvore de aplicação, e há diretórios rotulados 'inhouse' que indicam as coisas não destinados ao embarque. Ambos os protótipos e ferramentas internas podem ser desenvolvidas desta forma. Além disso, o código do protótipo é sempre útil para referência quando começamos um projeto next-gen 'ao vivo' com base em nossa aprendizagem do protótipo.