C'è molta documentazione "Git for Perforce Users" là fuori, ma apparentemente molto poco del contrario.

Ho usato Git solo in precedenza e recentemente ho iniziato un lavoro in cui devo usare molto Perforce e mi ritrovo molto confuso per la maggior parte del tempo. I concetti a cui sono abituato da Git sembrano non mappare affatto Perforce.

Qualcuno è interessato a mettere insieme alcuni suggerimenti per l'utilizzo di Perforce per qualcuno che è abituato a Git?

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 annotateo 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 setper 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 simpleper visualizzare i comandi di base necessari per lavorare con Perforce.

La più grande differenza tra git e p4, a cui nessuna delle risposte esistenti si rivolge, è che usano diverse unità di astrazione.

• In git, l'astrazione è la patch (aka diff, aka changeset). Un commit in git è essenzialmente l'output di esecuzione difftra lo stato precedente e quello corrente dei file sottoposti a commit.
• Per forza, l'astrazione è il file . Un commit in p4 è il contenuto completo dei file nel commit in quel momento. Questo è organizzato in un elenco di modifiche, ma le revisioni stesse vengono archiviate in base al file e l'elenco di modifiche raccoglie semplicemente diverse revisioni dei file insieme.

Tutto il resto deriva da questa differenza . La ramificazione e l'unione in git è indolore perché, dal punto di vista dell'astrazione di git, ogni file può essere completamente ricostruito applicando una serie di patch in ordine, e quindi per unire due rami, è sufficiente applicare tutte le patch sul ramo di origine che non sono presenti nel ramo di destinazione nel ramo di destinazione nell'ordine corretto (supponendo che non vi siano patch su entrambi i rami che si sovrappongono).

Le filiali di Perforce sono diverse. Un'operazione di diramazione in copia copierà i file da una sottocartella all'altra e quindi contrassegnerà il collegamento tra i file con metadati sul server. Per unire un file da un ramo a un altro ( integrationin termini perfetti), perforce esaminerà il contenuto completo del file nella "testa" del ramo di origine e il contenuto completo del file nella testa del ramo di destinazione e se necessario si fondono usando un antenato comune. Non è in grado di applicare le patch una ad una come git can, il che significa che le fusioni manuali avvengono più spesso (e tendono ad essere più dolorose).

Probabilmente non c'è molta documentazione del genere perché Perforce è un sistema di controllo delle revisioni piuttosto tradizionale (più vicino a CVS, Subversion, ecc.) E normalmente è considerato meno complicato dei moderni sistemi di controllo distribuito distribuito.

Cercare di mappare i comandi dall'uno all'altro non è l'approccio giusto; i concetti dei sistemi di controllo di revisione centralizzato e distribuito non sono gli stessi. Invece, descriverò un flusso di lavoro tipico in Perforce:

1. Esegui p4 editsu ogni file che si desidera modificare. Devi dire a Perforce quali file stai modificando. Se stai aggiungendo nuovi file, usa p4 add. Se stai eliminando i file, usa p4 delete.
2. Apporta le modifiche al codice.
3. Esegui p4 changeper creare un changeset. Qui puoi creare una descrizione della tua modifica e, facoltativamente, aggiungere o rimuovere file anche dal tuo changeset. È possibile eseguire p4 change CHANGE_NUMBERper modificare la descrizione in un secondo momento, se necessario.
4. È possibile apportare ulteriori modifiche al codice, se necessario. Se è necessario aggiungere / modificare / eliminare altri file, è possibile utilizzare p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Esegui p4 syncper estrarre le ultime modifiche dal server.
6. Esegui p4 resolveper risolvere eventuali conflitti dalla sincronizzazione.
7. Quando sei pronto per inviare la modifica, esegui p4 submit -c CHANGE_NUMBER.

È possibile utilizzare p4 revertper ripristinare le modifiche ai file.

Nota che puoi lavorare su più changeset contemporaneamente purché nessuno dei loro file si sovrapponga. (Un file nel client Perforce può essere aperto in un solo changeset alla volta.) Questo a volte può essere utile se si hanno piccole modifiche indipendenti.

Se ti trovi nella necessità di modificare i file che hai già aperto in un altro changeset, puoi creare un client Perforce separato oppure puoi riporre il changeset esistente per in seguito p4 shelve. (A differenza di git stashscaffalature, i file nella struttura locale non vengono ripristinati, quindi è necessario ripristinarli separatamente.)