Os arquivos * .xccheckout no Xcode5 devem ser ignorados no VCS?


157

A Apple introduziu um novo tipo de arquivo relacionado ao projeto no Xcode 5: "xccheckout".

Este arquivo está localizado no diretório ".xcodeproj / project.xcworkspace / xcshareddata /" e parece que está relacionado ao sistema de controle de versão do projeto.

Um arquivo de exemplo está aqui: http://pastebin.com/5EP63iRa

Suponho que esse tipo de arquivo deva ser ignorado no VCS, mas não tenho certeza.

Então, aqui estão as perguntas:

  1. O "xccheckout" deve ser ignorado?
  2. Qual é seu propósito?

Esta questão tende a ser bastante relevante; portanto, gostaria que fosse mais gramatical e sintaticamente correto. Se você é um falante nativo de inglês ou é extremamente proficiente em inglês, gostaria de pedir uma ajuda para verificar meu idioma. Obrigado!
Artem Abramov

1
Pequenas alterações sugeridas: "A Apple introduziu um novo", "Um arquivo de exemplo está aqui:". Há uma citação incompatíveis em questão 1.
Sofi Software LLC

3
Eu sempre se referem ao github / gitignore repo para saber quais arquivos devem ser ignorados -> github.com/github/gitignore/blob/master/Objective-C.gitignore
eliocs

Respostas:


109

Você deve fazer o check-in em um .xccheckoutarquivo Xcode 5 ; em geral, os arquivos xcshareddatadevem ser confirmados.

Um .xccheckoutarquivo contém metadados sobre quais repositórios são usados ​​em uma área de trabalho. Para um único projeto em um único repositório que não faz muita diferença. Mas se você estiver usando um espaço de trabalho que possui vários projetos de diferentes repositórios, a presença de um .xccheckoutarquivo no espaço de trabalho permite ao Xcode saber quais são todos os componentes que compõem um espaço de trabalho e onde obtê-los.


8
Se não fosse para ser compartilhado, a Apple o armazenaria e, .xcuserdataportanto, deveria ser incluído.
21813 Joshcodes

4
Como eu disse na minha resposta, o arquivo xccheckout contém informações para todos os repositórios usados ​​em uma área de trabalho. Esse é o caso, independentemente do sistema SCM que eles usam - esse espaço de trabalho pode estar em svn ou git, e seus projetos podem estar em uma mistura de repositórios svn e git.
Chris Hanson

72
Parece que o xccheckout contém chaves e nomes específicos para a máquina de cada desenvolvedor ... Assim que executo o xcode, ele altera algumas chaves no arquivo e altera algo chamado IDESourceControlWCCName de <string> OurCompanyAPI </string> para <string > our_company_api / string> - o último sendo o nome que eu usei ao clonar o repo. Se esse arquivo deve ser compartilhado, a Apple fez um trabalho muito ruim.
amigos estão dizendo sobre herr grumps

7
Quando verificamos esse arquivo, todos os meus colegas de trabalho recebem um IDESourceControlProjectIdentifier diferente ... para que nosso .xccheckout seja modificado a cada confirmação. -_-
Cœur

9
Independentemente do objetivo original da Apple, os .xccheckoutarquivos estão causando alguns problemas insanos no Xcode 6 beta, e eu decidi removê-los do VCS. Parece estar relacionado a algum bug de cache, e acredito que o Xcode pode regenerá-los automaticamente do VCS, a cada vez.
eonil

63

O *.xccheckoutarquivo contém metadados do VCS e, portanto, não deve ser verificado no VCS.

Por outro lado: verificar esse arquivo provavelmente não criará dificuldades de mesclagem ou outros problemas.

Se você deseja ignorar este arquivo (o que eu recomendo), adicione esta linha aos do seu projeto .gitignore:

*.xccheckout

A solução da Abizern não funcionará para projetos dentro de um espaço de trabalho. Porque, quando você usa um espaço de trabalho, o caminho para o *.xccheckoutarquivo será: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. E na verdade ignora mais do que você gostaria.

Edit: Este arquivo existe para gerenciar o conhecimento do Xcode dos possivelmente muitos sistemas VCS em seu projeto, consulte a resposta de Chris Hanson . Para> 99% dos projetos, o arquivo .xccheckout é um exagero na configuração.


1
Seria ótimo se você pudesse expandir essa afirmação "ela realmente ignora mais do que você gostaria". Especificamente, alguns exemplos de outros arquivos que entram nessa pasta que devem ser verificados.
Mark Edington

Acompanhamento: estou usando um .gitignore de Adam nesta pergunta . Está disponível como uma essência e tem alguma descrição do conteúdo da pasta xcshareddata.
Mark Edington

@ Mark : Ignora o project.xcworkspace/. Isso pode estar bem por enquanto, mas eu não contaria com isso para novas versões do Xcode.
Berik

6
Esta resposta é incorreta, e o padrão de GitHub .gitignoreque oferece aos desenvolvedores devem não especificar*.xccheckout
Chris Hanson

2
Depois de incluir esse arquivo nos meus repositórios desde que foi apresentado, recentemente comecei a removê-lo de todos os meus repositórios. Isso está criando conflitos de mesclagem o tempo todo, principalmente em projetos que incluem minhas próprias estruturas como submódulos. E então não ganho nada com esse arquivo, pois uso o git para gerenciamento de submodule. Boa tentativa, Apple, obrigado, mas não, obrigado.
Pascal

38

Depende. O arquivo contém referências ao repositório remoto que você está usando. Se você estiver usando um VCS centralizado, como o Perforce ou o Subversion, o repositório remoto de todos será o mesmo e você poderá e deve fazer o check-in do arquivo.

Se você estiver usando um VCS distribuído, como Mercurial ou git, mas usando-o como se fosse um CVCS (em outras palavras, todo mundo clonou de um repositório compartilhado diretamente para o espaço de trabalho pessoal em sua máquina), você ainda pode querer verificá-lo no.

No entanto, se você estiver usando um DVCS com todos com seu próprio clone remoto, por exemplo, usando o GitHub em seu padrão de uso padrão, NÃO deseja fazer o check-in deste arquivo. Se o fez, suas solicitações de recebimento solicitarão as configurações do repositório para ser copiado no arquivo xccheckout de todos os outros, mas as configurações do seu repositório serão diferentes das de todos os outros, porque você está usando repositórios remotos diferentes.


1
Esta resposta me parece a melhor. Verificá-los estava causando chats desnecessários nas diferenças para a nossa equipe confirmar. Eu adiciono ao .gitignore o seguinte para mantê-los fora: * / .xcworkspace / xcshareddata / *. Xccheckout Ainda não entendo por que a Apple optou por armazenar redundantemente essas informações que, de qualquer maneira, estão na pasta .git (meu único palpite é: fazer as coisas funcionarem de forma consistente em VCS)
Juan Carlos Méndez

20

Sim, o Project.xccheckoutarquivo deve ser confirmado no seu repositório. O Xcode usa esse arquivo para informar aos outros que abrem a área de trabalho toda a lista de repositórios de controle de origem usados ​​pela área de trabalho e o local da cópia de trabalho em relação à área de trabalho, se esses repositórios são Git, SVN ou ambos.

Quando você abre a área de trabalho, o Xcode usa o Project.xccheckoutarquivo para notificar o usuário de que existem outros repositórios que fazem parte da área de trabalho e pergunta qual deve ser retirado. Ao fazer o check-out de repositórios adicionais, o Xcode coloca as cópias de trabalho na mesma estrutura de pastas relativa ao espaço de trabalho que estava quando o Project.xccheckoutarquivo foi gerado.

Como Chris Hanson disse, provavelmente não importa para um espaço de trabalho de um único repositório e projeto, mas para assuntos mais complexos será muito útil.

Você pode descobrir mais sobre isso no vídeo da sessão da WWDC 2013 Entendendo o controle de origem no Xcode ; a parte relevante começa em cerca de 15 minutos.


Esse arquivo é útil apenas se você usar o Xcode for SCM; caso contrário, você não precisará desse arquivo. E menos ainda, se você trabalhar com garfos git, nesse caso, o caminho do repositório será único por desenvolvedor
Carlos Ricardo

3

É isso que eu tenho no meu .gitignore para o Xcode.

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

Mantém qualquer coisa relacionada ao estado local da maneira como os projetos me procuram fora do repositório.

O arquivo xccheckout está abaixo aqui, portanto não é rastreado no meu sistema por padrão.

O Xcode ficou melhor e separou o que precisa ser compartilhado e o que precisa ser mantido localmente. Por exemplo; essas linhas ignoram os esquemas de construção padrão, o que é bom, porque você pode marcar esquemas de construção específicos como compartilhados e eles são colocados em um diretório que não é ignorado.

Os pontos de interrupção são ignorados, mas você pode marcar pontos de interrupção específicos como compartilhados entre projetos e eles também são colocados em um diretório que não é ignorado.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.