Questo è qualcosa su cui ho lavorato nelle ultime due settimane. Si sta ancora evolvendo, ma può essere utile. Nota che sono un dipendente di Perforce.
Un'introduzione a Perforce per gli utenti Git
Dire che passare da Git a Perforce o da Perforce a Git non è banale è un eufemismo. Per essere due strumenti che apparentemente fanno la stessa cosa, il loro approccio non potrebbe essere più diverso. Questo breve articolo cercherà di aiutare i nuovi utenti Perforce di Git a capire il nuovo mondo in cui si trovano.
Una breve deviazione prima di immergerci; se preferisci Git puoi usare Git con Perforce abbastanza bene. Forniamo uno strumento chiamato Git Fusion che genera repository Git mantenuti sincronizzati con il server Perforce. Le persone di Git e Perforce possono vivere in armonia lavorando sullo stesso codice, per lo più non influenzato dalla scelta del controllo della versione da parte dei loro colleghi. Git Fusions 13.3 è disponibile sul sito Web di Perforce . Deve essere installato dall'amministratore di Perforce, ma se lo installi scoprirai che la sua funzione di suddivisione del repository può essere molto utile come utente Git.
Se non riesci a convincere il tuo amministratore a installare Git Fusion, Git stesso viene fornito con un'associazione Perforce chiamata Git-P4 che ti consente di utilizzare Git per modificare e inviare file in un'area di lavoro Perforce. Ulteriori informazioni al riguardo sono disponibili all'indirizzo: https://git.wiki.kernel.org/index.php/GitP4
Ancora qui? Bene, diamo un'occhiata a Perforce.
Alcune differenze terminologiche da risolvere
Prima di entrare nei dettagli, dobbiamo esaminare brevemente un paio di differenze terminologiche tra Git e Perforce.
Il primo è di checkout . In Git è così che ottieni una copia del codice da un determinato ramo nella tua area di lavoro. In Perforce la chiamiamo sincronizzazione dalla riga di comando o dalla nostra GUI P4V "Ottieni la revisione più recente". Perforce utilizza la parola checkout da P4V op4 edit
dalla riga di comando per indicare che si prevede di modificare un file dal sistema di controllo della versione. Nel resto di questo documento, userò il checkout nel senso Perforce della parola.
Il secondo è Git commit rispetto a Perforce submit . Dove ti impegnerai in Git ti invierai in Perforce. Dato che tutte le operazioni avvengono contro il servizio di versioning condiviso di Perforce, Perforce non ha un equivalente per git push
. Allo stesso modo non abbiamo un pull
; il comando di sincronizzazione dall'alto si occupa di ottenere file per noi. Non esiste un concetto di invio locale puro in Perforce se non si sceglie di utilizzare il nostro strumento P4Sandbox descritto brevemente di seguito.
Concetti chiave in Perforce
Se dovessi semplificare Perforce su due concetti chiave, mi concentrerei sul deposito e sull'area di lavoro. Un deposito Perforce è un repository di file che risiede in un server Perforce. Un server Perforce può avere un numero qualsiasi di depositi e ogni deposito può contenere qualsiasi numero di file. Spesso sentirai che gli utenti di Perforce utilizzano il depot e il server in modo intercambiabile, ma sono diversi. Un sito Perforce può scegliere di avere più server, ma più comunemente tutti i file si trovano in un server.
Un'area di lavoro o client Perforce è un oggetto nel sistema che mappa una serie di file nel server Perforce in una posizione sul file system di un utente. Ogni utente dispone di un'area di lavoro per ogni macchina che utilizza e spesso gli utenti avranno più di un'area di lavoro per la stessa macchina. La parte più importante di un'area di lavoro è la mappatura o la vista dell'area di lavoro.
La vista dell'area di lavoro specifica il set di file nel depot che devono essere mappati sul computer locale. Questo è importante perché esiste una buona probabilità che non si desideri tutti i file disponibili sul server. Una vista dell'area di lavoro ti consente di selezionare solo il set che ti interessa. È importante notare che un'area di lavoro può mappare il contenuto da più depositi, ma può mappare il contenuto solo da un server.
Per confrontare Perforce con Git a questo proposito, con Git scegli e scegli il set di repository Git a cui sei interessato. Ogni repository è generalmente strettamente limitato per contenere solo i file correlati. Il vantaggio di questo è che non c'è alcuna configurazione da fare da parte tua; fai un clone git delle cose che ti interessano e il gioco è fatto. Questo è particolarmente utile se lavori solo con uno o due repository. Con Perforce devi dedicare un po 'di tempo alla raccolta e alla scelta dei bit di codice desiderati.
Molti negozi Perforce utilizzano flussi che possono generare automaticamente una vista dello spazio di lavoro oppure generano la vista utilizzando script o spazi di lavoro modello. Allo stesso modo molti lasciano i propri utenti per generare autonomamente le proprie aree di lavoro. Un vantaggio di essere in grado di mappare un numero di moduli in uno spazio di lavoro è che puoi facilmente modificare più moduli di codice in un unico check-in; puoi essere certo che chiunque abbia una vista client simile che si sincronizza con il tuo check-in avrà tutto il codice nello stato corretto. Questo può anche portare a un codice eccessivamente dipendente; la separazione forzata di Git può portare a una migliore modularità. Per fortuna, anche Perforce può supportare una rigida modularità. È tutta una questione di come si sceglie di utilizzare lo strumento.
Perché gli spazi di lavoro?
Penso che venendo da Git sia facile pensare che l'intero concetto di spazio di lavoro sia molto più problematico di quanto valga la pena. Rispetto alla clonazione di alcuni repository Git, questo è senza dubbio vero. Dove le aree di lavoro brillano e il motivo per cui Perforce è ancora in attività dopo tutti questi anni, è che le aree di lavoro sono un modo fantastico per abbattere progetti multi-milioni di file per gli sviluppatori, facilitando allo stesso tempo la creazione e il rilascio da cui estrarre tutti i sorgenti una fonte autorevole. Gli spazi di lavoro sono uno dei motivi principali per cui Perforce può ridimensionarsi così come lo è.
Le aree di lavoro sono anche belle in quanto il layout dei file nel deposito e il layout sul computer dell'utente possono variare se necessario. Molte aziende organizzano il proprio deposito in modo da riflettere l'organizzazione della propria azienda in modo che sia facile per le persone trovare contenuti per unità aziendale o progetto. Tuttavia il loro sistema di compilazione non potrebbe fregare di meno di questa gerarchia; l'area di lavoro consente loro di rimappare la gerarchia dei depositi in qualsiasi modo abbia senso per i loro strumenti. Ho anche visto questo usato da aziende che usano sistemi di costruzione estremamente inflessibili che richiedono che il codice si trovi in configurazioni molto specifiche che sono assolutamente fonte di confusione per l'uomo. Gli spazi di lavoro consentono a queste aziende di disporre di una gerarchia di fonti navigabile dall'uomo mentre i loro strumenti di costruzione ottengono la struttura di cui hanno bisogno.
Le aree di lavoro in Perforce non vengono utilizzate solo per mappare il set di file con cui un utente desidera lavorare, ma vengono anche utilizzate dal server per tenere traccia esattamente delle revisioni di ciascun file sincronizzato dall'utente. Ciò consente al sistema di inviare all'utente il set corretto di file durante la sincronizzazione senza dover scansionare i file per vedere quali file devono essere aggiornati. Con grandi quantità di dati questo può essere una vittoria di prestazioni considerevole. Questo è anche molto popolare nelle industrie che hanno regole di controllo molto rigide; Gli amministratori di Perforce possono facilmente tenere traccia e registrare quali sviluppatori hanno sincronizzato quali file.
Per ulteriori informazioni sulla piena potenza delle aree di lavoro Perforce, leggere Configurazione di P4 .
Pagamento esplicito vs. Pagamento implicito
Una delle maggiori sfide per gli utenti che passano da Git a Perforce è il concetto di checkout esplicito. Se sei abituato al flusso di lavoro Git / SVN / CVS di modificare i file e quindi dire al sistema di controllo della versione di cercare ciò che hai fatto, può essere una transizione estremamente dolorosa.
La buona notizia è che, se lo desideri, puoi lavorare con un flusso di lavoro in stile Git in Perforce. In Perforce puoi impostare l'opzione "allwrite" sul tuo spazio di lavoro. Ciò dirà a Perforce che tutti i file devono essere scritti su disco con il bit scrivibile impostato. È quindi possibile modificare qualsiasi file desiderato senza dirlo esplicitamente a Perforce. Per fare in modo che Perforce riconcili le modifiche apportate, è possibile eseguire lo "stato p4". Aprirà i file per aggiungere, modificare ed eliminare come appropriato. Quando si lavora in questo modo, si desidera utilizzare "p4 update" anziché "p4 sync" per ottenere nuove revisioni dal server; "p4 update" controlla le modifiche prima della sincronizzazione, quindi non bloccherà le modifiche locali se non hai ancora eseguito "p4 status".
Perché il checkout esplicito?
Una domanda che ricevo spesso è "perché mai vorresti usare il checkout esplicito?" A prima vista può sembrare una pazza decisione di progettazione, ma il checkout esplicito ha alcuni potenti vantaggi.
Uno dei motivi per utilizzare il checkout esplicito è che non è necessario eseguire la scansione dei file per le modifiche al contenuto. Mentre con progetti più piccoli il calcolo degli hash per ogni file per trovare differenze è abbastanza economico, molti dei nostri utenti hanno milioni di file in un'area di lavoro e / o hanno file di dimensioni di 100 megabyte, se non di dimensioni maggiori. Il calcolo di tutti gli hash in quei casi richiede molto tempo. Il checkout esplicito consente a Perforce di sapere esattamente con quali file deve funzionare. Questo comportamento è uno dei motivi per cui Perforce è così popolare nelle grandi industrie di file come l'industria dei giochi, dei film e dell'hardware.
Un altro vantaggio è che il checkout esplicito fornisce una forma di comunicazione asincrona che consente agli sviluppatori di sapere in generale su cosa stanno lavorando i loro colleghi, o almeno dove. Può farti sapere che potresti voler evitare di lavorare in una determinata area in modo da evitare un conflitto inutile, o può avvisarti del fatto che un nuovo sviluppatore nel team ha vagato nel codice che forse non hanno bisogno da modificare. La mia esperienza personale è che tendo a lavorare in Git o nell'uso di Perforce con allwrite su progetti in cui sono l'unico collaboratore o un collaboratore poco frequente e un checkout esplicito quando lavoro strettamente con un team. Per fortuna la scelta è tua.
Il checkout esplicito si adatta perfettamente anche al concetto Perforce di liste di modifiche in sospeso. Le liste dei cambiamenti in sospeso sono secchi in cui puoi mettere i tuoi file aperti per organizzare il tuo lavoro. In Git potresti potenzialmente utilizzare diversi rami come secchi per l'organizzazione del lavoro. I rami sono fantastici, ma a volte è bello essere in grado di organizzare il lavoro in più cambiamenti nominati prima di inviarlo effettivamente al server. Con il modello Perforce di potenzialmente mappare più filiali o più progetti in un'unica area di lavoro, le liste di modifiche in sospeso facilitano l'organizzazione di modifiche separate.
Se si utilizza un IDE per lo sviluppo come Visual Studio o Eclipse, consiglio vivamente di installare un plug-in Perforce per il proprio IDE. La maggior parte dei plug-in IDE eseguirà il checkout automatico dei file quando inizi a modificarli, liberandoti dal fare il checkout da solo.
Sostituzioni Perforce per funzionalità Git
git stash
==> p4 shelve
- git branching locale ==> scaffali Perforce o rami di attività
git blame
==> p4 annotate
o Perforce Timelapse View dalla GUI
Funzionante disconnesso
Esistono due opzioni per lavorare disconnessi dal servizio di controllo delle versioni di Perforce (questo è il nostro termine elegante per il server Perforce).
1) Utilizzare P4Sandbox per avere il versioning locale completo e le ramificazioni locali
2) Modifica i file come preferisci e usa 'p4 status' per dire a Perforce cosa hai fatto
Con entrambe le opzioni di cui sopra, puoi scegliere di utilizzare l'impostazione "allwrite" nell'area di lavoro in modo da non dover sbloccare i file. Quando si lavora in questa modalità, si desidera utilizzare il comando "p4 update" per sincronizzare i nuovi file anziché "p4 sync". "p4 update" controlla i file per le modifiche prima di sincronizzarli.
Avvio rapido di Perforce
Tutti i seguenti esempi saranno tramite la riga di comando.
1) Configura la tua connessione a Perforce
export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666
È possibile inserire queste impostazioni nel file di configurazione della shell, utilizzare p4 set
per salvarle su Windows e OS X o utilizzare un file di configurazione Perforce.
1) Creare uno spazio di lavoro
p4 workspace
# set your root to where your files should live:
Root: /Users/matt/work
# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/... //demo-workspace/dev/...
2) Ottieni i file dal server
cd /Users/matt/work
p4 sync
3) Verifica il file su cui vuoi lavorare e modificalo
p4 edit main/foo;
echo cake >> main/foo
4) Invialo al server
p4 submit -d "A trivial edit"
5) Esegui p4 help simple
per visualizzare i comandi di base necessari per lavorare con Perforce.