Il tuo passaggio due di "Apri l'intero progetto per la modifica" può contribuire meno di una comunicazione chiara nel team.
Uno degli aspetti importanti del lavoro di squadra è la comunicazione. Perforce può mostrare chi ha un file aperto in un set di modifiche. Se sto lavorando su un file e vedo che qualcun altro sta anche modificando il file, questo è di potenziale interesse per me - potremmo avere una collisione.
D'altra parte, se sto solo verificando i file che ho bisogno di aprire come ho bisogno di loro, i miei compagni di squadra non saranno così confusi su ciò a cui sto lavorando (non sono potenzialmente in grado di toccare ogni file nel progetto).
Inoltre, considera che il server stia mantenendo le informazioni su ciò che ogni specifica del cliente ha estratto. Aprendo tutti i file in progetti di grandi dimensioni questo tasserà il server un po 'di più (probabilmente non molto di più, ma ne rimane ancora).
L'apertura di ogni file limita l'uso del comando p4 aperto ' .
Una cosa è vedere tutto ciò che "sei l'unico a controllare questo file" nel tuo elenco di modifiche in sospeso. È piuttosto un altro vedere ogni file anche estratto da altre persone.
Come ci si abitua a perforare, si arriva al punto in cui ogni volta che si inizia a lavorare su un file, prima lo si controlla.
Una volta che hai estratto i file, idealmente collocherai questi file aperti in una lista di modifiche nominate invece di lasciare questo nella lista delle modifiche di default. Questo è di nuovo di aiuto nella comunicazione tra i membri del team ("hai xyz.java aperto in una lista di modifiche chiamata 'fix abc bug'"). Ciò facilita anche il lavoro su due cose contemporaneamente raggruppando i file in diversi elenchi di modifiche a seconda delle esigenze.
In p4v ciò avviene facendo clic con il pulsante destro del mouse sui file e selezionando "move to another changelist".
A meno che non blocchi i file (ci sono pro e contro a questo), potresti dover risolvere i conflitti anche nel submit, ma saprai prima che invii che devi unire, e il server non ti permetterà di fare il check-in dell'elenco di modifiche (questa è un'operazione atomica). Questo verrà visualizzato con un punto interrogativo nell'icona del file.
Un concetto p4 più avanzato è quello dei lavori all'interno di p4. Queste si integrano con mylyn all'interno di eclipse come attività.
Con un lavoro, si associano gli elenchi di modifiche a un lavoro. Puoi quindi tornare indietro per esaminare un lavoro e vedere quali modifiche sono state verificate per correggere questo particolare elemento.
Inoltre, con gateway di tracciamento dei difetti p4 puoi collegare p4 al tuo sistema di tracciamento dei bug preferito. Questo collegherà i job p4 ai bug in modo che le modifiche a uno vengano visualizzate nell'altro (inclusi i checklist dell'elenco delle modifiche p4 rispetto ai processi descritti nel sistema di tracciamento dei difetti).
Ho visto un enorme database di tracciamento dei bug costruito su processi p4.
Potresti trovare i p4 tutorial una risorsa utile.
Fai check out guarda sandbox p4 - è interessante e potresti trovare la ramificazione locale privata (pensa DVCS) per adattarla al tuo modo di lavorare (e puoi ottenere il repository su una pen drive e lavorare fuori linea).