에있는 bin 및 obj 폴더를 확인하지 않아야하는 이유는 매우 기본적인 질문 인 것 같습니다. 그러나 대답을 알고 싶어합니다. 소스 제어를 위해 Subversion (SVN)을 사용하고 있으며 모든 파일을 검사했지만 클라이언트가 bin 및 obj 폴더를 검사하지 않도록 SVN 규칙을 만들도록 요청했습니다.
bin 및 obj 폴더를 확인하지 않아야하는 이유는 무엇입니까?SVN
클라이언트는 솔루션 파일을 저장소 폴더 외부에 보관하도록 요청했습니다. 왜 그런가요?
임시 파일을 SVN에 추가하면 안됩니다. 일시적입니다. 전체 obj 디렉토리는 빌드 프로세스 중에 작성된 후 파기되는 파일로 구성됩니다. (물론, 소스 파일이 변경되지 않을 때 캐시와 같이 일부는 재사용되기 때문에 디스크에 남아 있기 때문에 각 빌드 후에 삭제되지 않는 유일한 이유입니다).
bin 디렉토리는 약간 다른 문제입니다. SVN에 바이너리 파일을 추가하는 것은 괜찮습니다. 이미 이미 이미 아이콘 및 이미지 파일에 대해이 작업을 수행했을 것입니다. 어떤 사람들은 빌드 된 바이너리를 추가합니다. 이것은 구성 관리 프로세스에 의존하는 결정이며, '잘못된'대답은 없습니다. 그러나 때로는 bin 디렉토리가 추가하지 않으려는 다른 파일로 가득 찰 수 있습니다. .net 앱을 빌드하는 경우 프로젝트의 일부가 아닌 종속 디렉토리에 bin 디렉토리가 복사됩니다. 그것들을 추가하면 아무런 이익이없는 저장소가 부풀려집니다. 마찬가지로 .pdb 디버그 기호 파일과 같은 bin에 지원 바이너리가 있습니다. 이것들은 실제로 필요하지도 않습니다.
솔루션 파일의 경우 .sln 파일이 하나 이상의 프로젝트 파일에 대한 "래퍼"일 뿐이므로 확인하지 않아도됩니다. 비주얼 스튜디오 프로젝트를 새 프로젝트로 구축하는 데 엄격하게 필요하지 않은 것은 필요에 따라 만들어집니다. 사용자가 각각 다른 프로젝트 그룹을 가진 자신의 .sln 파일을 만들어서 각 사용자마다 다른 파일로 만들 수 있다고 생각합니다. 그것은 체크인을 막는 이유가 될 것이므로 각 사용자는 서로의 사용자 정의 파일을 덮어 쓰지 않을 것입니다 (사용자가 svn에 저장된 파일의 수정을 방지 할 수있는 방법이 있지만).
그래서 당신의 구성 전략에 svn에 바이너리를 추가하지 않는 것 같습니다. 어떤 경우에는 pre-commit hook을 사용하여 우발적 인 사고를 방지하는 것이 좋습니다. 또한 사용자가 이러한 파일을 처음부터 추가하려고 시도하는 것을 돕기 위해 이러한 제외 사항을 클라이언트 측 전역 무시에 추가하는 것이 좋습니다.
"should not"는 모든 사람에게 적용되지 않아야합니다. 하지만 일반적으로 :
1) 코드에서 생성 될 수있는 바이너리를 체크인하지 마십시오.
2) SVN은 소스 코드 버전 시스템이며 바이너리를 염두에두고 설계되지 않았습니다. 예, SVN 및 기타 VCS는 바이너리를 처리 할 수 있지만 의도 한 목적이 아닙니다 (특히 포인트 1 이후)
3) 소스 코드에 의해 생성되므로 변경 될 수 있으며 라이브러리와 다릅니다. 거의 변하지 않습니다. VCS는 바이너리를 제대로 처리 할 수 없으므로 자주 변경되는 바이너리는 VCS에 세금을 부과합니다. 따라서 diff (델타)는 소스 코드만큼 효율적이지 않으므로 바이너리에 대한 모든 변경 사항을 저장하는 경향이 있습니다.
솔루션 (.sln) 파일을 볼 때 절대적으로 필요한 것은 아니지만 저장소 (.sln) 파일을 체크인하는 것이 이상적입니다. 그러나 전부는 아니더라도 대부분의 .NET 프로젝트는 Visual Studio 기반이며 빌드 목적으로도 .sln 파일을 사용하면 csproj (또는 다른 프로젝트) 파일이 아닌 sln 파일에서 msbuild를 호출 할 수 있으므로 작업이 훨씬 쉬워집니다. 적절한 의존성 컴파일, 병렬 컴파일 등과 같은 다른 이점을 얻을 수 있습니다.
왜 downvote? – manojlds
'이진 파일 없음'은 좋은 대답이 아닐 것입니다. 그것은 결국 이미지와 함께 작동하며 소스 코드로 간주됩니다. 내가 빌드 아티팩트를 직접 체크 인하는 것은 구현 자들이 훨씬 더 쉽게 살 수있게 해 주며 svn의 바이너리 델타는 사실 아주 훌륭하다. 아마 생각보다 좋다. – gbjbaanb
@gbjbaanb 답변에 바이너리가없는 부분은 어디입니까? 내 대답은''로 시작해서 모든 사람들에게 적용되지 않아야한다 '는 것과 같은 줄에서'일반적으로'라고 말하면서 "예, SVN과 다른 VCS는 바이너리를 처리 할 수 있지만 의도 한 목적이 아닙니다" 내가 안된다고 했니? 네가 나 한테 말했는지 아닌지 모르겠다. – manojlds
체크 아웃 할 때마다 사용자가 특정 파일이나 생성 된 출력 파일을 실제로 체크인하면 재 컴파일 된 출력 변경 내용이 다시 채워질 수 있습니다. bin, obj 및 .suo (.sln이 아님)를 시작 지점으로 무시하는 것이 좋습니다. 이렇게하면 컴파일로 다시 만들어지기 때문에 사용자마다 또는 빌드마다 다시 생성되는 것을 무시합니다.
왜 하향 투표 했나요? 적어도 LOL에 관해서는 commet을 남겨 둡니다. 당신이 대답을 안다고 생각한다면 스스로 대답하십시오. –
+1, 나에게 가혹한 것 같습니다 - "사용자 특정 파일을 체크인하지 마십시오"좋은 조언입니다. – gbjbaanb
@ gbjbaanb. 고마워요, 당신의 대답은 내가 만들고 있던 포인트의 확장 된 버전이며 당신의 대답에도 동의합니다. –
+1 답안에 동의하십시오.이 대답은 제가 아래 답변에서 제시 한 포인트를 확대합니다. –
@gbjbaand 훌륭한 답변입니다. 특히 당신이 .sln 파일에 대해 말한 것이 내 클라이언트가 .sln 파일에서 나를 괴롭히는 정확한 이유라고 생각합니다. – VJAI
덧붙여 말하자면, sln 파일에 설정할 수있는 "ignore-on-commit"변경 목록이 있습니다. 추가 한 경우 로컬 변경 내용을 커밋하지 않으려는 경우입니다. – gbjbaanb