2010-10-26 23 views
29

Spesso si verificano conflitti nel file di progetto Xcode (Project.xcodeproj/project.pbxproj) quando si uniscono rami (sto usando git). A volte è facile, ma a volte finisco con un file di progetto corrotto e devo tornare. Nel peggiore dei casi devo correggere manualmente il file di progetto in un secondo commit (che può essere schiacciato con il precedente) trascinando i file ecc.Unione di file di progetto Xcode

Qualcuno ha suggerimenti su come gestire i conflitti di merge in grandi e complessi file come il file di progetto Xcode?


EDIT-- Alcune questioni connesse:

Git and pbxproj

Should I merge .pbxproj files with git using merge=union?

RISORSE:

http://www.alphaworks.ibm.com/tech/xmldiffmerge

http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge

http://tdm.berlios.de/3dm/doc/thesis.pdf

http://www.cs.hut.fi/~ctl/3dm/

http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/

+0

Interessante domanda. sfortunatamente penso che non ci sia una soluzione - sono curioso di sapere se qualcuno riuscirà a trovare una buona risposta. In caso contrario, dai un'occhiata a http://stackoverflow.com/questions/3929087/dividing-a-project-into-multiple-xcode-project-files/3932613#3932613 :) –

risposta

7

1) rompere i vostri progetti fino nei più piccoli, librerie logiche/pacchetti. i progetti massicci sono regolarmente il segno di un cattivo design, come l'oggetto che fa troppo o è troppo grande.

2) design per semplificare la ricostruzione, questo aiuta anche a scrivere programmi che devono essere creati da più strumenti o IDE. molti dei miei 'progetti' possono essere ricostruiti aggiungendo una directory.

3) rimuovere le fasi di costruzione estranee. esempio: ho rimosso la fase di costruzione "Copia intestazioni" da tutti i progetti. includere esplicitamente i file specifici tramite la direttiva include.

4) utilizzare i file xcconfig laddove possibile. questo riduce anche il numero di modifiche che devi apportare quando aggiorni le tue build. I file xcconfig definiscono una raccolta di impostazioni di build e supportano #include. ovviamente, si cancellano le impostazioni definite dall'utente (maggioranza) da ciascun progetto e destinazione quando si definisce xcconfig da utilizzare.

5) per le dipendenze di destinazione: creare destinazioni che eseguono operazioni logiche, piuttosto che operazioni fisiche. questo di solito è un target script di shell o un target aggregato. ad esempio: "crea dipendenze", "esegui tutte le unit test", "crea tutto", "pulisci tutto". quindi non devi mantenere ogni dipendenza cambia in ogni passo - è come usare i riferimenti.

6) definire un comune "Albero delle sorgenti" per il codice e un secondo per le fonti di terze parti.

7) sono disponibili strumenti di generazione esterni. questa potrebbe essere un'opzione per te (almeno per alcuni dei tuoi obiettivi).

a questo punto, un xcodeproj sarà molto più semplice. richiederà un minor numero di modifiche e sarà molto facile da ricostruire. puoi andare molto oltre con questi concetti per ridurre ulteriormente la complessità dei tuoi progetti e build.

+0

Ottimi suggerimenti, sebbene eludano piuttosto che risolvere il problema. 1 + 6 lo sto già facendo. 4 + 5 prenderò in considerazione. 2 + 7 - potresti fornire maggiori informazioni? – Felixyz

+0

sì, fanno semplicemente progetti di file/strutture (e aggirano il problema più che risolverlo). 2) struttura i tuoi file sorgente, risorse, casi di test, ecc. In modo che tu possa facilmente ricreare qualsiasi obiettivo aggiungendo tutti i contenuti di una directory in un progetto (in particolare, i casi di test dovrebbero risiedere in un altro progetto o si dovrebbe avere un secondo obiettivo dedicato ai test che dovresti anche costruire aggiungendo tutto dalla dir unit_test al target unit_test). in questo modo, scriveresti e imposterai file sorgente (ecc.) in modo da poter ricostruire qualsiasi target in base alle sue (continue) dipendenze – justin

+0

(cont), al contenuto (intero) di una directory e a l'aggiunta di un xcconfig. se un progetto è corrotto o deve essere utilizzato in un altro ide (o versione di xcode), l'importazione richiede meno di 1 minuto. questo può anche aiutare a mantenere i bit inutilizzati fuori dall'albero del progetto principale. rende anche facile creare build combinate. se sei ossessivo riguardo alla correttezza della dichiarazione rispetto a ciò che viene esportato e alla visibilità (che dovrebbe essere sicuramente un problema se stai lavorando a programmi non banali), puoi creare una build combinata in un tempo molto breve. (segue) – justin

2

Il modo migliore che ho trovato è di istruire Git per trattare il file .pbxproj come un file binario. Ciò impedisce l'unione disordinata.

Aggiungi questo al file .gitatributes:

*.pbxproj -crlf -diff -merge 
+1

Che differenza fa questa unione fisica? – esbenr

+4

Se questo rende il file effettivamente binario, in che modo l'unione si semplifica? – damian

+1

si prega di controllare questi fuori: http://robots.thoughtbot.com/xcode-and-git-bridging-the-gap ---- Quote: A causa del formato personalizzato utilizzato in questo tipo di file, questo è esattamente quello che vogliamo Quando si verifica un conflitto di unione per questo file, git combina automaticamente le modifiche da entrambi i lati del conflitto, applicando prima le modifiche upstream. – chakming

2

per confrontare due progetti di Xcode aperto aperto FileMerge (Xcode aperto e selezionare Xcode (dal riquadro manu) -> Strumenti aperta per sviluppatori -> FileMerge) . ora fai clic sul pulsante "sinistra" e apri la directory principale del progetto xcode. fare clic sul pulsante "right" e aprire la directory principale del progetto xcode da confrontare.

Ora fai clic sul pulsante "Unisci"!

Questo è tutto!

+1

È più semplice, se si utilizza git: 'git config --global merge.tool opendiff' (è necessario eseguire una sola volta), quindi' git mergetool' lo avvierà per te. – damian

+1

Non sono sicuro che FileMerge abbia un supporto speciale per i file di progetto Xcode in particolare? – Benjohn

0

Un'altra opzione da considerare che può aiutare a ridurre il numero di volte in cui si verifica il problema. Per spiegare, chiamerò il ramo che i rami dei membri del team provengono dal ramo "sviluppo". Avere una convenzione nel proprio team che quando il file di progetto viene modificato, le modifiche (insieme a qualsiasi altra modifica richiesta per garantire l'integrità della build) vengono eseguite in un commit separato. Quel commit viene quindi selezionato sul ramo di sviluppo. Gli altri membri del team che pianificano di modificare il file di progetto nel loro ramo possono quindi selezionare i caratteri nel loro ramo o rebase il loro ramo nell'ultimo sviluppo. Questo approccio richiede comunicazione attraverso il team e una certa disciplina. Come ho detto, non sarà sempre possibile; su alcuni progetti potrebbe essere di grande aiuto e su alcuni progetti potrebbe non esserlo.

3

si potrebbe desiderare di provare https://github.com/simonwagner/mergepbx/

Si tratta di uno script che vi aiuterà a unire i file in modo corretto progetto XCode. Si noti che è ancora alfa.

Disclaimer: Sono l'autore di mergepbx.

+0

Simon, questo progetto è maturo al momento? –

+2

Beh, funziona per me - quindi sì? Purtroppo non c'è la possibilità di assicurarsi che funzioni davvero con tutto ciò che è là fuori, poiché non esiste documentazione sul formato del file di progetto. Quindi non sarà mai meglio di "funziona per me e nessuno si è lamentato finora". – Simon

+0

Simon - Dopo aver passato anni nello sviluppo e nel controllo qualità, ho sentito "bene, funziona per me", che mi spaventa. Forse è tutto ciò che abbiamo, ma ancora. –

Problemi correlati