Visual Studio 2010 Beta 2를 평가하는 동안 변환 된 디렉토리에서 vcproj 파일이 vcxproj 파일 이되었습니다 . 폴더 구조에 대한 설명 (\ Source Files, \ Header Files 등)을 포함하는 것처럼 보이는 각 프로젝트와 함께 vcxproj.filter 파일 도 있습니다.
이러한 필터 파일을 사용자별로 유지해야합니까, 아니면 전체 dev 그룹에서 공유하고 SCC에 체크인해야한다고 생각하십니까?
나의 현재 생각은 그것들을 체크인하는 것이지만, 그렇게하지 않는 이유가 있는지, 또는 내가 확실히 체크인해야하는 좋은 이유가 있는지 궁금합니다.
다른 사람의 컴퓨터를 보면 폴더 구조가 일치하지만 논리적으로 항목을 재구성하고 싶을 때 이점이 있습니다.
답변:
우리는 의도적으로 .filter를 뽑았습니다. .vcxproj MSBuild 형식으로 변환 할 때 .vcproj 외부의 파일 정보. 그 이유 중 하나는 필터가 순전히 논리적 인 관점이며 다른 팀 구성원이 다른 관점을 원할 수도 있다는 점입니다. 다른 하나는 빌드가 프로젝트 파일의 타임 스탬프를 확인하도록 설정되어 있으며, 변경된 경우 다시 빌드를 트리거한다는 것입니다. 빌드 할 소스 파일이 다르거 나 설정이 다를 수 있기 때문입니다. 실제로 빌드 trigging과 같은 방식으로 배송했다면, 필터가 빌드에 영향을 미치지 않기 때문에 필터가 변경 되었기 때문에 단순히 재 빌드를 트리거하고 싶지 않다는 아이디어가있었습니다.
방금 Git을 사용하면 .filter 파일을 병합하기 위해 통합으로 처리하도록 표시하여 더 간단하게 만들 수 있음을 알았습니다. 그냥 라인을 추가하십시오 :
*.vcxproj.filters merge=union.gitattributes 파일에.
자세한 내용은 병합 충돌 방지를 위해 .gitattributes 사용 을 참조하십시오.
merge=union합니까? 다른 약속은 없습니다. 그 지식과 * .filter-files가 어떻게 보이는지에 대한 폭 넓은 아이디어를 통해 왜 merge=union그 파일에 좋은 아이디어 인지 쉽게 알 수 있습니다.