TFS: creare un nuovo progetto da uno esistente in TFS

Question

Qual è il modo migliore per creare un progetto completamente nuovo in TFS copiandone uno esistente?

Ho un progetto ASP.NET che avrà oltre 50 "versioni" all'anno. Ogni versione è un'entità distinta che deve rimanere indipendente da tutti gli altri. Una volta creato, voglio assicurarmi che qualsiasi modifica a uno (il progetto di origine o la copia) non influenzi l'altro.

Questo è solo per il controllo del codice sorgente. Non ho bisogno di copiare alcun oggetto di lavoro.

Nel mondo pre-TFS lo farei semplicemente copiando la cartella che conteneva tutti i file di progetto. Questo mi ha portato al 90% della strada verso la nuova app, che poi ho potuto personalizzare per la nuova versione. È molto raro che io debba effettivamente aggiungere funzionalità all'applicazione di base e anche quando lo faccio non influisce mai sulle app esistenti. È ancora possibile utilizzare TFS copiando le mie cartelle locali e aggiungendo la copia in TFS come nuovo progetto?

Qualche suggerimento? Un ramo per versione sembra il modo "standard" per farlo, ma presto mi ritroverò con dozzine di rami che non sono realmente correlati, e preferirei mantenere ogni nuovo progetto come se fosse un progetto distinto, senza alcuna possibilità di cambiamenti in uno che influenzano l'altro.

Grazie!

• Grazie per le risposte. Penso che tu mi abbia dato abbastanza informazioni per iniziare. Richard, grazie per il dettaglio. Ero un po 'preoccupato che potesse essere troppo facile accidentalmente unire i rami.

Answer 1

ci sono due domande qui:

1) È meglio copiare/incollare o ramificare?

Mi azzarderei a dire che la copia/incolla non è mai appropriata. A meno che tu non stia molto attento (almeno, esegui 'tfpt treeclean' immediatamente prima di copiare), è probabile che finirai per controllare alcuni file inappropriati nella nuova posizione. Inoltre, si userà FAR più spazio sul server, dal momento che deve memorizzare più di 50 copie complete invece di solo diff.

Non c'è praticamente alcun pericolo che i rami vengano "accidentalmente" sospinti lungo la linea. L'unione di rami richiede almeno 3 passaggi deliberati: pending the merge (a sua volta una procedura guidata di 4 pagine), quindi risolvere tutti i conflitti, quindi effettuare il check-in.

Né è probabile che tu ti confonda sul tuo posto nell'albero. TFS utilizza la "ramificazione dello spazio del percorso". Ciò significa che i rami appaiono all'utente come luoghi fisici separati nell'albero dei sorgenti, piuttosto che semplici tag di versione in cima allo stesso percorso.Poiché i rami assomigliano a cartelle, puoi eseguire tutte le normali operazioni di cartella su di essi: Cloak (non scaricarli nell'area di lavoro locale), Autorizzazione (in particolare, la rimozione dell'autorizzazione di lettura di qualcuno assicurerà che non possano nemmeno vederla), Elimina o distruggi (quando hai veramente finito con loro).

2) Quando è opportuno creare un nuovo progetto di squadra?

Questo è un argomento più complesso in generale. Official guidance. My opinion.

Tuttavia, direi che il tuo caso è semplice: non farlo. I progetti di gruppo hanno un sacco di spese generali. C'è uno finite number you can create on a server ... mai. Non dimenticare anche altre forme di overhead, come il tempo impiegato dall'amministratore del progetto per eseguire il port su tutte le tue impostazioni e il tempo impiegato da ogni sviluppatore del tuo team per ricollegare il suo Team Explorer.

Tutto per cosa? I link sopra illustrano dettagliatamente le forme di sottostruttura che possono essere create all'interno di un singolo Team Project. In breve, quasi tutto è possibile. Le uniche aree che sono un po 'carenti sono le query di squadra e le definizioni di costruzione, che sono limitate a una singola cartella contenitore, e alcune impostazioni come il checkout esclusivo che sono tutte o niente. A meno che tu non abbia una squadra molto grande o molto diversificata, è improbabile che i vantaggi dei progetti di squadra separati per versione siano superiori agli svantaggi.

Ovviamente, se un "rilascio" è un evento importante che segnala un cambiamento nelle pratiche SCM, è tutta un'altra storia. Nuovo SCM => nuovo modello di processo => ​​nuovo progetto di squadra. Ma dubito che lo faccia più di 50 volte l'anno :)

Answer 2

Si consiglia di utilizzare la ramificazione. Crea un ramo per ogni versione dal ramo principale. Finché non si uniscono i rami rimarranno indipendenti. Le modifiche al ramo principale riguarderanno solo i rilasci creati dopo che tali modifiche sono state apportate.

Si potrebbe copiare i file e creare un nuovo progetto, ma si può incorrere in un paio di problemi:

• I progetti "ricordare" che erano in TFS, c'è un po 'di lavoro manuale per ripulire i file speciali, ecc
• TFS può rallentare quando si dispone di molti progetti, a fronte di un unico progetto con rami

Answer 3

Questo potrebbe sembrare ovvio ma dovresti creare solo un nuovo progetto per un "nuovo progetto". Sembra che quello di cui parli siano versioni diverse dello stesso progetto.

Se si desidera mantenere codebase separati per le versioni precedenti, come hanno detto gli altri rispondenti, la ramificazione del codice è la scelta migliore. Funziona bene quando vuoi unire correzioni di bug dalla tua ultima versione anche in versioni precedenti.

Tuttavia, se davvero si devono realmente avere nuovi progetti, si utilizza ancora la ramificazione nello stesso modo.