Quais arquivos do Eclipse é apropriado colocar sob controle de origem, além das fontes, obviamente?
No meu projeto, especificamente, estou pensando em:
.metadata / *
project-dir / .project
project-dir / .classpath
project-dir / .settings / *
Se houver algum destes dos quais depende, explique suas diretrizes.
Respostas:
Os metadados não devem ser gerenciados no controle de origem. Eles contêm principalmente dados relevantes para o seu espaço de trabalho.
A única exceção são os .launcharquivos XML (definição do iniciador).
Eles são encontrados em
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
E eles devem ser copiados para o diretório do projeto: Quando o projeto for atualizado, essas configurações serão exibidas na caixa de diálogo "Executar configuração".
Dessa forma, esses arquivos de parâmetros de inicialização também podem ser gerenciados no SCM.
(Aviso: Do desmarque a opção "configurações de exclusão quando recurso associado é excluído" na Run / Lançamento / configuração de lançamento painel de preferências: é comum a soft-excluir um projeto, a fim de importá-lo de volta - para forçar uma reinicialização do metadados do eclipse. Mas essa opção, se marcada, removerá os parâmetros detalhados de inicialização!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
deve estar no seu SCM (especialmente .projecte de .classpathacordo com a documentação do Eclipse ).
O objetivo é que qualquer pessoa possa fazer check-out / atualizar seu espaço de trabalho do SCM e importar o projeto Eclipse para o espaço de trabalho do Eclipse.
Para isso, você deseja usar apenas caminhos relativos no caminho .class, usando recursos vinculados .
Nota: é melhor se project-dirreferir a um diretório de projeto "externo", não a um diretório criado no espaço de trabalho do eclipse. Dessa forma, as duas noções (espaço de trabalho eclipse vs. espaço de trabalho SCM) são claramente separadas.
Como o ipsquiggle menciona no comentário, e como já mencionei em uma resposta antiga , você pode realmente salvar a configuração de inicialização como arquivo compartilhado diretamente no diretório do projeto. Toda a configuração de inicialização pode ser versionada como os outros arquivos de projeto.
(Na postagem do blog Dica: Criando e compartilhando configurações de inicialização do KD)
.projectignorada por enquanto seja apenas para o seu espaço de trabalho. Mas não prive todos os outros usuários da definição de projeto comum do Eclipse que eles podem importar rapidamente em seu espaço de trabalho Eclipse, apenas porque você possui uma definição extra que atenderia apenas às suas necessidades do momento.
Atualmente, estou trabalhando em um projeto no qual temos os arquivos .project e .cproject sob controle de origem. A idéia era que as configurações relacionadas aos caminhos da biblioteca e às diretivas de link se propagassem pela equipe.
Na prática, não funcionou muito bem, as fusões quase sempre retornam em um estado conflituoso que precisa ser desconfigurado fora do eclipse e, em seguida, o projeto é fechado e reaberto para que as alterações entrem em vigor.
Eu não recomendaria mantê-los no controle de origem.
Não vale nada que os arquivos de configuração do CDT não sejam compatíveis com o controle de origem. Há um erro registrado para os arquivos .cproject mudando com muita frequência e causando conflitos. Consulte Compartilhar arquivos do projeto cdt no repositório sempre causa conflitos .
Alguns projetos, como os que usam o Maven, gostam de gerar os arquivos .project com base em POMs.
Dito isto, além disso - .metadata NÃO deve estar no controle de origem. Seu projeto precisará determinar se o projectdir / .settings funciona, com base em como você planeja gerenciar padrões e tais. Se você pode confiar honestamente em seus desenvolvedores para configurar seu ambiente com base no padrão e não precisar personalizar nada de especial para nenhum projeto, não precisará inseri-los. Eu, recomendo configurar todos os projetos especificamente . Isso permite que os desenvolvedores trabalhem nas coisas de vários projetos no mesmo espaço de trabalho sem precisar alterar as configurações padrão e para trás e torna as configurações muito explícitas, substituindo as configurações padrão para corresponder aos padrões do projeto.
A única parte difícil é garantir que todos fiquem sincronizados. Mas na maioria dos casos, você pode copiar os arquivos .settings de um projeto para outro. Se houver algo que você não deseja especificamente no controle de origem, faça o equivalente à configuração svn: ignore para eles, se o seu SCM suportar.
O arquivo .classpath é definitivamente um bom candidato para o scm, pois configurá-lo manualmente pode ser muito trabalhoso e será difícil para novos desenvolvedores entrarem no projeto. É verdade que pode ser gerado a partir de outras fontes; nesse caso, você faria o check-in na outra fonte.
Quanto às configurações, isso depende das configurações. Essa é uma área cinzenta, mas algumas configurações são quase obrigatórias e é conveniente poder verificar um projeto, importá-lo no Eclipse e ter tudo configurado e pronto.
Portanto, em nosso projeto, mantemos uma cópia da pasta .settings chamada CVS.settings e temos uma tarefa ant para copiá-la para .settings. Quando você obtém o projeto no CVS, chama a tarefa ant 'eclipsify' para copiar as configurações padrão para a nova pasta .settings. Quando você define as configurações necessárias para todos os que estão desenvolvendo o projeto, as junta novamente à pasta CVS.settings e as confirma ao CVS. Dessa forma, salvar as configurações no SCM se torna um processo consciente. Requer que os desenvolvedores mesclem essas configurações de volta às pastas .settings periodicamente, quando grandes alterações são registradas. Mas é um sistema simples que funciona surpreendentemente bem.
Eu diria que nenhum deles. Eles provavelmente contêm informações que são relevantes apenas para sua estação de trabalho (estou pensando em caminhos para bibliotecas e tudo). E se alguém da sua equipe não estiver usando o Eclipse?
Considerar:
.classpath
.project
.launch
Estes devem estar no controle de versão, desde que você mantenha o uso de caminhos relativos ao projeto. Isso permite que outros desenvolvedores verifiquem o projeto e comecem a trabalhar imediatamente, sem ter que passar por toda a dor de instalação que outros desenvolvedores também passaram.
Você pode ficar tentado a incluir .metadata no controle de versão, para que os desenvolvedores do Eclipse possam verificar uma área de trabalho inteira e pré-configurá-la com todos os projetos certos, mas inclui muitas informações específicas do usuário que, sempre que alguém trabalhar nela, serão alterar, por isso aconselho a NÃO INCLUIR .metadata. É fácil construir um espaço de trabalho local apenas importando todos os projetos existentes do Eclipse.
Passei muitas horas definindo as configurações do espaço de trabalho do eclipse para novos colegas (e para mim). O que acabei fazendo foi copiar meus próprios .metadata para a nova máquina do desenvolvedor.
Se você estiver trabalhando em uma equipe, acho que os candidatos a seguir são muito bons para manter o controle de versão:
commonguia, escolhaSave as > shared file. Isso o coloca diretamente na pasta do projeto, para que possa ser SCM com o restante do projeto.