I file * .xccheckout in Xcode5 devono essere ignorati in VCS?

157

Apple ha introdotto un nuovo tipo di file relativo al progetto in Xcode 5: "xccheckout".

Questo file si trova nella directory ".xcodeproj / project.xcworkspace / xcshareddata /" e sembra che sia correlato al sistema di controllo della versione del progetto.

Un file di esempio è qui: http://pastebin.com/5EP63iRa

Suppongo che questo tipo di file debba essere ignorato in VCS, ma non ne sono sicuro.

Quindi, ecco le domande:

"Xccheckout" dovrebbe essere ignorato?
Qual è il suo scopo?

— Artem Abramov
fonte

Questa domanda tende ad essere abbastanza rilevante; quindi vorrei che fosse più grammaticalmente e sintatticamente corretto. Se sei di madrelingua inglese o sei molto abile in inglese, vorrei chiedere aiuto per controllare la mia lingua. Grazie!

— Artem Abramov,

1

Modifiche minori suggerite: "Apple ha introdotto un nuovo", "Un file di esempio è qui:". C'è una citazione non corrispondente nella domanda 1.

— Sofi Software LLC

3

Mi riferisco sempre al repository github / gitignore per sapere quali file dovrebbero essere ignorati -> github.com/github/gitignore/blob/master/Objective-C.gitignore

— eliocs

109

È necessario.xccheckout archiviare un file Xcode 5 ; in generale, i file in xcshareddatadovrebbero essere impegnati.

Un .xccheckoutfile contiene metadati su quali repository sono utilizzati in un'area di lavoro. Per un singolo progetto in un singolo repository che non fa molta differenza. Ma se stai utilizzando uno spazio di lavoro che ha più progetti da diversi repository, la presenza di un .xccheckoutfile nell'area di lavoro consente a Xcode di sapere quali sono tutti i componenti che compongono uno spazio di lavoro e dove trovarli.

— Chris Hanson
fonte

8

Se non fosse pensato per essere condiviso, Apple lo memorizzerebbe .xcuserdatae dovrebbe essere incluso.

— Joshcodes,

4

Come ho detto nella mia risposta, il file xccheckout contiene informazioni per tutti i repository utilizzati in un'area di lavoro. Questo è il caso indipendentemente dal sistema SCM che usano : un tale spazio di lavoro può essere in svn o git, ei suoi progetti possono essere in un mix di repository svn e git.

— Chris Hanson,

72

Sembra che xccheckout contenga chiavi e nomi specifici per la macchina di ogni sviluppatore ... Non appena eseguo xcode cambia alcune chiavi nel file e cambia qualcosa chiamato IDESourceControlWCCName da <string> OurCompanyAPI </string> a <string > our_company_api / string> - quest'ultimo è il nome che ho usato durante la clonazione del repository. Se questo file dovrebbe essere condiviso, allora Apple ha svolto un lavoro piuttosto scadente.

— Herr Grumps,

7

Quando controlliamo questo file, tutti i miei collaboratori ottengono un IDESourceControlProjectIdentifier diverso ... quindi il nostro .xccheckout viene modificato con ogni commit. -_-

— Cœur

9

Indipendentemente da ciò che Apple intendeva inizialmente, i .xccheckoutfile stanno causando alcuni problemi folli su Xcode 6 beta e ho deciso di rimuoverli da VCS. Sembra essere correlato ad alcuni bug di memorizzazione nella cache e credo che Xcode possa rigenerarli automaticamente da VCS, per ogni volta.

— eonil,

63

Il *.xccheckoutfile contiene metadati VCS e pertanto non deve essere verificato nel VCS.

D'altra parte: il check-in in questo file probabilmente non creerà difficoltà di unione o altri problemi.

Se vuoi ignorare questo file (che raccomando) dovresti aggiungere questa linea a quella del tuo progetto .gitignore:

*.xccheckout

La soluzione di Abizern non funzionerà per progetti all'interno di un'area di lavoro. Perché, quando si utilizza un'area di lavoro, il percorso del *.xccheckoutfile sarà: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. E in realtà ignora più di quanto vorresti.

Modifica: questo file esiste per gestire la conoscenza di Xcode dei possibili sistemi VCS nel tuo progetto, vedi la risposta di Chris Hanson . Per> 99% dei progetti, il file .xccheckout è un overkill di configurazione.

— Berik
fonte

1

Sarebbe fantastico se si potesse espandere su questa affermazione "in realtà ignora più di quanto si vorrebbe". In particolare, alcuni esempi di altri file che vanno in quella cartella che dovrebbero essere archiviati.

— Mark Edington,

Follow-up: sto usando un .gitignore di Adam da questa domanda . È disponibile come sintesi e ha una descrizione dei contenuti della cartella xcshareddata.

— Mark Edington,

@ Mark : ignora il project.xcworkspace/. Questo potrebbe essere giusto per ora, ma non vorrei contare su quello per le nuove versioni di Xcode.

— Berik,

6

Questa risposta non è corretta e lo standard di GitHub .gitignoreche fornisce agli sviluppatori non dovrebbe specificare*.xccheckout

— Chris Hanson,

2

Dopo aver incluso questo file nei miei repository da quando è stato introdotto, di recente ho iniziato a rimuoverlo da tutti i miei repository. Questa cosa crea continuamente conflitti di unione , principalmente in progetti che includono i miei framework come sottomoduli. E quindi non ottengo nulla da questo file poiché utilizzo git per la gestione dei sottomoduli. Bel tentativo, Apple, grazie, ma no grazie.

— Pascal,

38

Dipende. Il file contiene riferimenti al repository remoto che si sta utilizzando. Se stai usando un VCS centralizzato come Perforce o Subversion, il repository remoto di tutti sarà lo stesso e quindi puoi e dovresti controllare il file.

Se stai usando un VCS distribuito come Mercurial o git, ma utilizzandolo come se fosse un CVCS (in altre parole, tutti clonati da un repository condiviso direttamente sul loro spazio di lavoro personale sulla loro macchina), potresti comunque voler controllarlo nel.

Tuttavia, se si utilizza un DVCS con chiunque abbia il proprio clone remoto, ad esempio utilizzando GitHub nel suo modello di utilizzo standard, NON si desidera controllare questo file. Se lo si è fatto, le richieste pull richiederanno le impostazioni del proprio repository per essere copiato nel file xccheckout di tutti gli altri, ma le impostazioni del tuo repository saranno diverse da quelle di tutti gli altri perché stai utilizzando tutti repository remoti diversi.

— Tim Band
fonte

1

Questa risposta mi sembra la migliore. Il check-in è stato causa di inutili chiacchiere sui diff per il nostro team. Aggiungo a .gitignore quanto segue per tenerli fuori: * / .xcworkspace / xcshareddata / *. Xccheckout Non capisco ancora perché Apple abbia scelto di archiviare in modo ridondante queste informazioni che comunque si trovano nella cartella .git (la mia unica ipotesi è di far funzionare le cose in modo coerente su VCS)

— Juan Carlos Méndez,

20

Sì, il Project.xccheckoutfile deve essere eseguito il commit nel tuo repository. Xcode utilizza questo file per indicare agli altri che aprono l'area di lavoro l'intero elenco di repository di controllo del codice sorgente utilizzati dallo spazio di lavoro e la posizione della copia di lavoro relativa allo spazio di lavoro, indipendentemente dal fatto che tali repository siano Git, SVN o entrambi.

Quando si apre l'area di lavoro, Xcode utilizza il Project.xccheckoutfile per informare l'utente che ci sono altri repository che fanno parte dell'area di lavoro e chiede quale debba essere verificato. Quando si estraggono repository aggiuntivi, Xcode inserisce le copie funzionanti nella stessa struttura di cartelle relativa allo spazio di lavoro di quando erano al momento della Project.xccheckoutgenerazione del file.

Come ha detto Chris Hanson , probabilmente non ha importanza per uno spazio di lavoro con un singolo repository, ma per affari più complessi sarà davvero molto utile.

Puoi saperne di più al riguardo nel video della sessione del WWDC 2013 Comprensione del controllo del codice sorgente in Xcode ; la parte pertinente inizia a circa 15 minuti.

— Calrion
fonte

Questo file è utile solo se si utilizza Xcode per SCM, altrimenti non è necessario quel file. E ancora meno se lavori con forchette git, in quel caso, il percorso repo sarà unico per sviluppatore

— Carlos Ricardo,

3

Questo è ciò che ho nel mio .gitignore per Xcode.

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

Mantiene tutto ciò che riguarda lo stato locale del modo in cui i progetti mi cercano fuori dal repository.

Il file xccheckout è sotto qui quindi non è tracciato sul mio sistema per impostazione predefinita.

Xcode è migliorato e separa ciò che deve essere condiviso e ciò che deve essere mantenuto localmente. Per esempio; queste righe ignoreranno gli schemi di compilazione predefiniti, il che va bene perché è possibile contrassegnare schemi di compilazione specifici come condivisi e vengono inseriti in una directory che non viene ignorata.

I punti di interruzione vengono ignorati, ma è possibile contrassegnare punti di interruzione specifici come condivisi tra progetti e vengono anche inseriti in una directory che non viene ignorata.

— Abizern
fonte