singolo insidia più pericolosa:
Una volta che un componente viene definito, non è possibile spostare un elemento al di fuori di questa componente (è possibile copiare e ricreare altrove, ma si perderanno la sua storia)
Singolo best practice più utile:
Comprendere bene la natura di un componente UCM: è circa la coerenza .
Un componente è un insieme di file di cui:
- evolve come una singola unità,
- è etichettato (baselined) nel suo complesso,
- è ramificato nel suo complesso.
Se è possibile apportare evoluzioni senza toccare un altro gruppo di file, è probabile che si abbiano due componenti.
Esempio di componenti:
- un'applicazione (o una parte autonoma di un'applicazione)
- una biblioteca tecnica
- un insieme impaccato del fascicolo (per il rilascio)
L' un documento che dovrebbe guidarvi a definire i componenti è l'Architettura Applicativa (che prende le specifiche di business e funzionali e p trasferirli su applicazioni che verranno poi specificate a livello tecnico e implementate).
Quando tutti questi componenti sono definiti, si hanno due approcci per la loro gestione:
approccio di sistema (ogni componenti è scrivibile in un progetto UCM): utile per l'avvio di un progetto, ma ingombranti con progetto legacy: non è necessario mettere una baseline su ogni singolo componente semplicemente perché 3 file sono stati modificati in uno di questi componenti.
approccio componente: uno o due componenti scrivibili, il resto è lì solo come non modificabile componente. Questo è un approccio scalabile, che consente di definire un progetto per componente da sviluppare, con una "configurazione fissa" (cioè "le altre linee di base", che rappresenta stati fissi dei componenti non modificabili che è necessario avere per compilare il modificabile: è possibile modificare in qualsiasi momento questa configurazione, ovvero è possibile rebase le linee di base della base del componente non modificabile ogni volta che lo si desidera).
È possibile definire il maggior numero di progetti e corsi d'acqua che si desidera, che consente di visualizzare facilmente il merge workflow.
Ricorda: un flusso rappresenta uno sforzo di sviluppo .
Non chiamare un flusso dopo una risorsa (come VonC_stream), ma dopo un compito o un insieme di compiti da fare in quella Stream (come in APP_LCH_R32_Dev: Sviluppo per il rilascio 32 ° del mio Avvio applicazioni)
Nota : UCM è solo alcuni metadati in cima a ClearCase: anche se un gruppo di file è definito come un componente UCM, nulla ti impedisce di creare rami classici non UCM, checkout o check-in (in viste non UCM).
Esiste un pericolo nella creazione di troppi componenti a grana fine o avere troppe dipendenze tra i componenti?
Sì, è per questo che l'architettura applicativa è importante. Di nuovo, una volta definito un componente, non è possibile spostare elementi tra questi componenti.
Altri dettagli per conoscere componenti è la loro disposizione:
myVob
myComponent1
myComponent2
myComponent3
componente A radice è sempre al primo livello di sotto di un VOB.
È inoltre possibile definire un componente come un tutto Vob, ma io non lo consiglio (l'aggiunta di un Vob stressare server Vob. L'aggiunta di una directory all'interno di un Vob costo nulla esistente)
Questo significa che se si definisce alcune biblioteche tecniche come componenti, non si può andare come:
myLibs
Apache
ant
xalan
xerces
ma dovrete fare:
myLibs
apapche_ant
apache_xalan
apache_xerces
avvertimento finale: dipendenza (il vero marchio di un sistema di gestione della configurazione)
Uno dei principali vantaggi di UCM (o così ho pensato al momento - 2003 -) è la dipendenza.
Sedipende da B e ho inserito A nel mio progetto, esso includerà automaticamente B nello stesso progetto.
Magico.
Ma è rotto.
- In primo luogo, non eseguire mai la dipendenza basata su root (un componente basato su radice è un insieme di file).Si romperà alla prima di sovrapposizione:
A1
B1
B2
Qui è necessario B2 per continuare a costruire A, ma A parte da A1 basate su B1: B2 override B1. Non appena inserisci una linea di base su A (A2), è finita. Non sarai più in grado di cambiare B. A baseline del parassita (chiamato A2!?) Sarà stato inserito nel componente (non modificabile!) B a causa della sovrapposizione.
- includono sempre le dipendenze in un componente senza radici
ADep1
A1
BDep1
B1
BDep2
B2
Qui avere componenti senza radici ADep e BDep (un componente senza radici è un componente speciale che aggrega altri senza radici o componenti di root-based)
Hai ancora un override, ma questa volta tra i componenti senza radici.
Che sarà ancora fare una linea di base del parassita (su BDep, chiamato A2), ma almeno si sarà in grado di rebase BDep2 in altre linee di base in seguito (BDep3, BDep4 ...)
Maggiori informazioni su questo Incoherences and Inconsistencies of ClearCase UCM, con Rational counter-arguments here (e subito dopo il loro post, prova che i loro argomenti non sono molto buoni per non dire altro).
Leggi anche How to Leverage Clearcase’s features
Ho appena completato la risposta in risposta al tuo commento. – VonC
È stato appena aggiunto l'avviso di base parassita sulla dipendenza del componente. – VonC