struttura di controllo del codice sorgente per il prototipo e implementazione reale

Question

Come dovremmo strutturare un progetto in controllo del codice sorgente con il prototipo + 'reale' implementazione dell'applicazione?

Noi lavoriamo su un prototipo per un nuovo progetto e memorizziamo che nel controllo del codice sorgente (Subversion, ma la questione dovrebbe essere indipendente da quello) con la seguente struttura nel nostro repository principale con tutti i nostri progetti:

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

Con una stagista lavoriamo sul design per la logica del dominio, e abbiamo intenzione di avviare l'attuazione della logica di dominio nella settimana successiva.

Abbiamo pensato le seguenti possibilità:

• un archivio completamente separato (il tirocinante ha poche settimane di esperienza con controllo del codice sorgente / Subversion)

• un progetto separato nel nostro repository principale

• un ramo (ad esempio branches/prototype) nell'ambito del progetto esistente per il prototipo e quindi utilizzare trunk per l'attuazione 'vero'

Quale struttura che vi consigliamo per questa situazione?

Answer 1

Dopo aver trascorso diversi anni come un gestore SCM per un grande reparto di software con diversi programmi, la mia raccomandazione sarebbe quella di fare un ramo per i seguenti motivi:

1. Se il prototipo non funziona si può lasciar morire ramo in quel punto.

2. Se il prototipo funziona allora è possibile unire di nuovo in un tronco di sviluppo primario

3. Si può continuare a lavorare sul prototipo, se lavori del progetto primario deve iniziare

Subversion è adatto per gestire tutti questi scenari. È inoltre possibile utilizzare le etichette per aiutare a controllare il codice pure. Questi dovrebbero essere descrittivo possibile quindi chiunque che viene dopo si può facilmente determinare che cosa il codice è per.

Answer 2

Quello che facciamo è di avere un archivio separato chiamato prototipi dove abbiamo messo tutti i nostri progetti di test / gioco / esperimento / prototipo. Se qualcosa vale la pena, ci spostiamo al proprio repository.

Answer 3

Abbiamo un albero di applicazione, e ci sono le directory etichettate 'inhouse' che indicano le cose non destinati per la spedizione. Entrambi i prototipi e strumenti interni possono essere sviluppati in questo modo. Inoltre, il codice prototipo è sempre a portata di mano per riferimento quando si comincia un progetto next-gen 'live' sulla base della nostra cultura dal prototipo.