버전 제어에 속하는 이클립스 파일은 무엇입니까?

버전 제어에 속하는 이클립스 파일은 무엇입니까?

분명히 소스 외에 소스 제어 하에 두는 것이 적절한 이클립스 파일은 무엇입니까?

제 프로젝트에서, 특히 다음과 같은 것들이 궁금해요.

vmdk/*
파일 이름/.프로젝트
classpath project-path/.classpath
dll/* project-interval/.dll/*

이것들 중에 의존하는 것이 있다면, 당신의 가이드라인을 설명해주세요.

메타데이터는 소스 제어에서 관리되지 않아야 합니다.대부분 작업 공간과 관련된 데이터가 포함되어 있습니다.

는 유한예는입니다..launchXML 파일(실행기 정의).

다음에서 확인할 수 있습니다.

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

그리고 다음과 같이 프로젝트 디렉토리에 복사해야 합니다.프로젝트를 새로 고치면 해당 구성이 "구성 실행" 대화 상자에 표시됩니다.

이렇게 하면 이러한 시작 매개 변수 파일을 SCM에서도 관리할 수 있습니다.

(경고: Run/Launching/Launch Configuration 환경설정 패널에서 "연결된 리소스가 삭제될 때 구성 삭제" 옵션의 선택을 취소합니다.프로젝트를 다시 가져오기 위해 프로젝트를 소프트 삭제하고 이클립스 메타데이터를 강제로 다시 초기화하는 것이 일반적입니다.그러나 이 옵션을 선택하면 자세한 실행 매개 변수가 제거됩니다!)

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

SCM)에 ..project그리고..classpath이클립스 문서에 따르면).

누구나 자신의 SCM 작업영역을 체크아웃/업데이트하고 Eclipse 프로젝트를 Eclipse 작업영역으로 가져올 수 있습니다.

이 경우 연결된 리소스를 사용하여 .classpath의 상대 경로만 사용하려고 합니다.

참고: 다음과 같은 경우가 더 좋습니다.project-dir이클립스 작업 공간 아래에 생성된 디렉토리가 아닌 "외부" 프로젝트 디렉토리를 참조합니다.SCM Workspace가 구분되어 있습니다.SCM 작업 공간)이 명확하게 분리되어 있습니다.

---

ipsquiggle이 코멘트에서 언급했듯이, 그리고 제가 이전 답변에서 언급했듯이, 실제로 시작 구성을 프로젝트 디렉토리에 직접 공유 파일로 저장할 수 있습니다.그러면 모든 시작 구성을 다른 프로젝트 파일처럼 버전을 지정할 수 있습니다.

(블로그 게시물 팁: KD에서 실행 구성 만들기 및 공유)

저는 현재 .project와 .c project 파일을 소스 제어 하에 두는 프로젝트를 진행하고 있습니다.이 아이디어는 라이브러리 경로 및 링크 지시어와 관련된 설정이 팀 전체에 전파된다는 것이었습니다.

실제로는 그다지 잘 작동하지 않습니다. 병합은 거의 항상 충돌 상태로 돌아옵니다. 이 상태는 일식이 아닌 외부에서 충돌을 해제해야 합니다. 그런 다음 변경 사항을 적용하려면 프로젝트가 닫혔다가 다시 엽니다.

소스 제어 상태로 유지하는 것은 권장하지 않습니다.

CDT 구성 파일이 소스 제어에 적합하지 않다는 것은 아무 가치도 없습니다..c 프로젝트 파일에 대한 버그가 매우 자주 변경되어 충돌이 발생합니다. 저장소에서 cdt-project 파일을 공유하면 항상 충돌이 발생합니다.를 참조하십시오.

메이븐을 사용하는 프로젝트와 같은 일부 프로젝트는 POM을 기반으로 .project 파일을 생성하는 것을 좋아합니다.

즉, 그 외에는 .metadata가 소스 제어에 있으면 안 됩니다.당신의 프로젝트는 프로젝트가 제대로 진행되는지 여부를 결정해야 합니다.표준 등을 관리하는 방법에 따라 설정이 이루어집니다.개발자가 표준을 기반으로 환경을 설정할 수 있고 프로젝트를 위해 특별한 것을 사용자 지정할 필요가 없다면 개발자를 투입할 필요가 없습니다.모든 프로젝트를 구체적으로 구성하는 것이 좋습니다.이를 통해 개발자는 기본 설정을 앞뒤로 변경하지 않고도 동일한 작업 공간에서 여러 프로젝트의 항목을 작업할 수 있으며, 프로젝트의 표준과 일치하는 기본 설정을 재정의하여 설정을 매우 명시적으로 지정할 수 있습니다.

유일하게 어려운 점은 그들 모두가 동기화를 유지하도록 하는 것입니다.그러나 대부분의 경우 프로젝트 간에 .settings 파일을 복사할 수 있습니다.소스 제어에 특별히 원하지 않는 것이 있으면 SCM에서 지원하는 경우 svn:ignore를 설정하는 것과 동등한 작업을 수행합니다.

.classpath 파일은 수작업으로 설정하는 것이 많은 작업이 될 수 있고 새로운 개발자들이 프로젝트에 참여하기 어려울 것이기 때문에 scm에 체크인하기에 확실히 좋은 후보입니다.다른 소스에서 생성될 수 있으며, 이 경우 다른 소스를 체크인할 수 있습니다.

.settings의 경우 설정에 따라 다릅니다.여기는 회색 영역이지만 일부 설정은 거의 필수이며 프로젝트를 체크아웃하고 Eclipse에서 가져와 모든 것을 설정하고 이동할 수 있는 것이 편리합니다.

따라서 프로젝트에서는 CVS.settings라는 .settings 폴더의 복사본을 유지 관리하고 이를 .settings에 복사해야 하는 작업을 수행합니다.CVS에서 프로젝트를 가져오면 'eclpsify' 개미 작업을 호출하여 기본 설정을 새 .settings 폴더에 복사합니다.프로젝트에서 개발하는 모든 사람에게 필요한 설정을 구성할 때 이러한 설정을 CVS.settings 폴더에 다시 병합하고 CVS에 커밋합니다.이러한 방식으로 SCM에 설정을 저장하는 것이 의식적인 프로세스가 됩니다.큰 변경 사항이 체크인될 때마다 개발자는 이러한 설정을 .settings 폴더에 다시 병합해야 합니다.하지만 이것은 놀라울 정도로 잘 작동하는 간단한 시스템입니다.

그들 중 누구도 말할 수 없습니다.워크스테이션에만 관련된 정보가 포함되어 있을 가능성이 높습니다(라이브러리 등의 경로에 대해 생각하고 있습니다).또한 팀의 누군가가 이클립스를 사용하지 않는 경우에는 어떻게 해야 합니까?

고려 사항:

.classpath
.project
.launch

프로젝트 관련 경로를 계속 사용하는 한 이러한 경로는 버전 관리 상태에 있어야 합니다.이를 통해 다른 개발자들이 프로젝트를 확인하고 다른 개발자들이 겪는 모든 설정 고통을 겪지 않고 바로 작업을 시작할 수 있습니다.

버전 제어에 .metadata를 포함하면 Eclipse 개발자가 전체 작업 공간을 체크아웃하고 모든 올바른 프로젝트로 사전 구성할 수 있지만, 사용자별 정보가 많이 포함되어 있기 때문에 작업할 때마다 변경되므로 .metadata는 포함하지 않는 것이 좋습니다.기존의 모든 Eclipse 프로젝트를 가져오는 것만으로도 로컬 작업 공간을 쉽게 구축할 수 있습니다.

새로운 동료(및 나 자신)를 위해 일식 작업 공간 설정을 구성하는 데 너무 많은 시간을 보냈습니다.결국 제가 하게 된 것은 제 자신의 .metadata를 새로운 개발자 기계에 복사하는 것이었습니다.

만약 당신이 팀에서 일하고 있다면, 저는 다음이 버전 관리를 유지하기에 매우 좋은 후보라고 생각합니다.

• 설치된 JRE 및 해당 이름
• 서버 런타임 환경
• Java 편집기 템플릿
• 버전 제어 키보드 바로 가기 키
• 프로젝트별 설정을 제공하지 않는 플러그인 설정
• 메이븐 설정
• 사전 구성된 관점
• ...

.metadata에 버전 제어 기능을 넣으려고 시도한 적은 없지만, 10년 동안 이 파일들에 버전 제어 기능을 사용하고 있습니다.

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

주된 이유는 이클립스가 때때로 파일을 손상시키기 때문입니다.버전 제어가 없으면 이상해지고 오류를 추적하기가 어려워집니다.버전 제어를 사용하면 "테스트 클래스를 배포하려는 이유는 무엇입니까?"를 즉시 확인할 수 있습니다.또는 "Maven과 Eclipse가 동일한 클래스 경로를 사용하는 이유는 무엇입니까?"(https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605) 로 이동).

버전 제어를 사용하면 발생 시기를 확인하고 작업 중인 구성 파일 집합으로 쉽게 돌아갈 수 있습니다.

m2e를 사용하는 경우: 느린 "Maven 프로젝트 가져오기" 대신 빠른 "기존 프로젝트 가져오기"로 프로젝트를 가져올 수 있습니다.

이 접근 방식의 단점은 Eclipse가 이러한 파일 중 일부를 임의로 변경하는 것처럼 보인다는 것입니다.대부분의 플러그인은 안정적으로 유지하지만 일부 플러그인은 LinkedHashMap 대신 HashMap을 사용하므로 요소의 순서가 항상 변경됩니다.즉, 다음을 커밋할 때 추가 단계가 있습니다.수정된 설정을 확인하고 먼저 처리합니다.

이는 또한 팀 전체가 어떤 경고를 활성화해야 하는지와 같은 몇 가지 기준에 동의해야 한다는 것을 의미합니다.많은 사람들이 이것을 함께 일하지 않는 것처럼 추가적인 문제로 보는 것은 흥미롭습니다.

제 경험으로는, 그 파일들이 안정될 때까지 몇 주가 걸립니다.부분적으로는 여러분이 점차적으로 이클립스를 조정하는 방법을 배우기 때문이고, 부분적으로는 사람들이 만지지 말아야 할 것을 배우기 때문입니다.이는 작업 환경의 품질을 개선하는 데 소요되는 시간 또는 시간 낭비라고 생각할 수 있습니다(예: 책상을 깔끔하게 유지하는 것).

"설정 먼저 커밋"의 이점은 다음과 같습니다.그것은 사람들이 더 자주 그리고 더 작은 조각으로 (즉, "한 번에 하나의 생각"과 내가 우연히 발견한 수천 개의 다른 관련 없는 것들에 대해" 대신에 "한 번에 하나의 생각"과 더 유사하게) 커밋하게 만듭니다.무엇을 다시 작업하고 있었습니까?")

노련한 개발자로서, 저는 "작은 약속" 방식을 선호하게 되었습니다. 단지 궤도에 오르기가 더 쉽고 여러분의 생각과 변화를 더 작고 관리하기 쉬운 단계로 분류하는 경향이 있습니다.이를 통해 복잡성을 줄일 수 있습니다.모든 사람이 공 하나로 저글링을 할 수 있고, 아무도 20개로 저글링을 할 수 없습니다.

PS: 특정 설정 파일의 경우 WTP의 "테스트 배포 시도"와 같이 알려진 오류가 슬금슬금 들어오지 않도록 장치 테스트를 수행합니다.이렇게 하면 "모든 것을 커밋합니다. 너무 바쁩니다." 단계에서 도움이 됩니다.

언급URL : https://stackoverflow.com/questions/337304/which-eclipse-files-belong-under-version-control