버전 관리에 속하는 Eclipse 파일은 무엇입니까?
답변:
메타 데이터는 소스 제어에서 관리하지 않아야합니다. 그들은 주로 관련된 데이터를 포함 하여 작업 공간을.
유일한 예외는 .launchXML 파일 (런처 정의)입니다.
그들은에서 발견된다
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
프로젝트 디렉토리로 복사해야합니다. 프로젝트를 새로 고치면 해당 구성이 "구성 실행"대화 상자에 표시됩니다.
이렇게하면 해당 시작 매개 변수 파일을 SCM으로 관리 할 수도 있습니다.
(경고 : 음주 옵션의 선택을 취소 "관련 리소스 삭제 삭제 구성" 에서 실행 / 시작 / 실행 구성의 기본 설정 패널 : 그것은에 공통 다시 가져올하기 위해 프로젝트를 소프트 - 삭제 -의 재 초기화를 강제로 이클립스 메타 데이터.하지만이 옵션을 선택하면 자세한 시작 매개 변수가 제거됩니다!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
당신의 SCM (특히에 있어야 .project하고 .classpath에 따라 이클립스 문서 ).
목표는 누구나 자신의 SCM 작업 영역을 체크 아웃 / 업데이트하고 Eclipse 프로젝트를 Eclipse 작업 영역으로 가져올 수 있다는 것입니다.
이를 위해 연결된 리소스를 사용하여 .classpath에 상대 경로 만 사용하려고 합니다 .
참고 : project-dirEclipse 작업 공간에서 작성된 디렉토리가 아닌 "외부"프로젝트 디렉토리를 참조 하는 것이 좋습니다 . 이렇게하면 두 개념 (이클립스 작업 영역 대 SCM 작업 영역)이 명확하게 분리됩니다.
으로 ipsquiggle는 주석에 언급, 나는이 언급 한 것처럼 오래된 대답에 , 당신은 실제로 발사 구성을 저장할 수있는 파일을 공유 프로젝트 디렉토리에 직접. 그런 다음 모든 시작 구성을 다른 프로젝트 파일처럼 버전화할 수 있습니다.
(블로그 게시물 팁 : KD에서 실행 구성 작성 및 공유 )
.project은 작업 공간 을 위해서만 무시하십시오. 그러나 이클립스 작업 공간에서 신속하게 가져올 수있는 공통 Eclipse 프로젝트 정의의 다른 모든 사용자를 박탈하지 마십시오. 단지 필요한 순간에 맞는 하나의 추가 정의가 있기 때문입니다.
CDT 구성 파일이 소스 제어에 적합하지 않다는 것은 가치가 없습니다 . .cproject 파일에 대한 버그가 매우 자주 변경 되어 충돌을 일으 킵니다 . 저장소에서 cdt-project 파일을 공유하면 항상 충돌이 발생합니다를 참조하십시오 .
Maven을 사용하는 프로젝트와 같은 일부 프로젝트는 POM을 기반으로 .project 파일을 생성하는 것을 좋아합니다.
즉, -.metadata 이외의 소스 제어에 있어서는 안됩니다. 프로젝트는 표준 관리 방법 등에 따라 projectdir / .settings가 수행되는지 여부를 결정해야합니다. 표준을 기반으로 환경을 설정하도록 개발자를 정직하게 신뢰할 수 있고 프로젝트에 대해 특별한 것을 사용자 정의 할 필요가 없다면 프로젝트를 넣을 필요가 없습니다. 저에게 모든 프로젝트를 구체적으로 구성하는 것이 좋습니다. . 이를 통해 개발자는 기본 설정을 앞뒤로 변경하지 않고도 동일한 작업 공간에서 여러 프로젝트의 작업을 수행 할 수 있으며 기본 설정이 프로젝트 표준과 일치하는 것을 무시하여 설정을 매우 명시 적으로 만듭니다.
어려운 부분은 모두 동기화 상태를 유지하는 것입니다. 그러나 대부분의 경우 .settings 파일을 프로젝트에서 프로젝트로 복사 할 수 있습니다. 소스 제어에서 원하지 않는 것이 있으면 SCM에서 지원하는 경우 svn : ignore를 설정하는 것과 동일하게 수행하십시오.
.classpath 파일은 수작업으로 설정하는 것이 많은 작업이 될 수 있고 새로운 개발자가 프로젝트에 참여하기 어려울 수 있기 때문에 scm을 확인하기에 좋은 후보입니다. 다른 소스에서 생성 될 수 있으며,이 경우 다른 소스를 체크인해야합니다.
설정은 설정에 따라 다릅니다. 이것은 회색 영역이지만 일부 설정은 거의 필수이며 프로젝트를 체크 아웃하고 Eclipse로 가져 와서 모든 것을 설정하고 진행하는 것이 편리합니다.
따라서 프로젝트에서 CVS.settings라는 .settings 폴더의 복사본을 유지 관리하고이를 .settings에 복사하는 개미 작업이 있습니다. CVS에서 프로젝트를 가져 오면 'eclipsify'ant 태스크를 호출하여 기본 설정을 새 .settings 폴더에 복사하십시오. 프로젝트에서 개발하는 모든 사람이 필요로하는 설정을 구성하면 해당 설정을 CVS.settings 폴더로 다시 병합하여 CVS에 커밋합니다. 이렇게하면 SCM에서 설정을 저장하는 것이 의식적인 과정이됩니다. 큰 변경 사항이 체크인 될 때마다 개발자가 해당 설정을 .settings 폴더로 다시 병합해야합니다. 그러나 놀랍도록 잘 작동하는 간단한 시스템입니다.
나는 그들 중 누구도 말하지 않았다. 워크 스테이션에만 관련된 정보가 포함되어있을 가능성이 높습니다 (라이브러리 및 모든 경로에 대해 생각하고 있습니다). 또한 팀의 누군가가 Eclipse를 사용하지 않는 경우 어떻게해야합니까?
치다:
.classpath
.project
.launch
프로젝트 상대 경로를 사용하는 한 버전 관리가 있어야합니다. 이를 통해 다른 개발자가 프로젝트를 확인하고 다른 개발자가 겪은 모든 설정 과정을 거치지 않고도 바로 작업을 시작할 수 있습니다.
버전 제어에도 .metadata를 포함시키려는 유혹이있을 수 있으므로 Eclipse 개발자는 전체 작업 공간을 체크 아웃하고 모든 올바른 프로젝트로 사전 구성 할 수 있지만 누구나 작업 할 때마다 많은 사용자 특정 정보를 포함합니다. .metadata를 포함하지 않는 것이 좋습니다. 기존의 모든 Eclipse 프로젝트를 가져 오기만하면 로컬 작업 공간을 쉽게 구축 할 수 있습니다.
common탭 에서을 선택합니다Save as > shared file. 이것은 프로젝트 폴더에 직접 놓아서 나머지 프로젝트와 함께 SCM 할 수 있습니다.