[version-control] 소스 제어에 타사 라이브러리 저장

애플리케이션이 의존하는 라이브러리를 소스 제어에 저장해야합니까? 내 한 부분은해야한다고 말하고 다른 부분은 안된다고합니다. 앱에서 몇 가지 기능에 의존하기 때문에 전체 앱을 축소하는 20MB 라이브러리를 추가하는 것은 잘못된 느낌입니다 (비록 상당히 많지만). 단지 jar / dll을 저장해야합니까, 아니면 배포 된 프로젝트의 zip / tar를 저장해야합니까?

다른 사람들은 무엇을합니까?



답변

저장소에 타사 라이브러리가있을뿐만 아니라 향후 라이브러리 업데이트에서 쉽게 추적하고 병합 할 수있는 방식으로 수행하는 것이 좋습니다 (예 : 보안 수정 등). Subversion을 사용하는 경우 적절한 공급 업체 분기를 사용하는 것이 좋습니다.

제 3 자의 코드를 수정하기 전에 지옥에서 추운 날이 될 것이라는 것을 알고 있다면 (@Matt Sheppard가 말했듯이) 외부가 합리적이며 전환이 매우 쉬워진다는 추가 이점을 제공합니다. 최신 버전의 라이브러리는 보안 업데이트 또는 필수 새 기능으로 인해 바람직합니다.

또한 필요한 경우 길고 느린로드 프로세스를 저장하는 코드베이스를 업데이트 할 때 외부 항목을 건너 뛸 수 있습니다.

@Stu Thompson은 소스 제어에 문서 저장 등을 언급합니다. 더 큰 프로젝트에서는 송장 / 청구서 / 회의록 / 기술 사양 등을 포함하여 소스 제어에 전체 “클라이언트”폴더를 저장했습니다. 전체 촬영 경기. 비록, 에헴, 당신이 사용할 수있게 할 저장소와는 별개의 저장소에 이것들을 저장하는 것을 기억하십시오 : 다른 개발자들; 클라이언트; 당신의 “브라우저 소스 뷰”… 기침 … 🙂


답변

10 년 후 프로젝트를 빌드하는 데 필요한 모든 것을 저장합니다.

2017 년 편집 :이 답변은 나이가 들지 않았습니다 .-). ant 또는 make와 같은 오래된 것을 여전히 사용하고 있다면 위의 내용이 여전히 적용됩니다. 종속성 관리와 함께 maven 또는 graddle (예 : .net의 Nuget)과 같은 더 현대적인 것을 사용하는 경우 버전 제어 서버와 함께 종속성 관리 서버를 실행해야합니다. 두 가지 모두에 대한 좋은 백업이 있고 종속성 관리 서버가 이전 종속성을 삭제하지 않는 한 괜찮습니다. 종속성 관리 서버의 예는 Sonatype Nexus 또는 JFrog Artifcatory 등을 참조하세요 .


답변

라이브러리를 저장하지 마십시오. 엄격히 말해서 프로젝트의 일부가 아니며 리비전 제어 시스템에서 쓸데없는 공간을 차지합니다. 그러나 프로젝트에서 사용하는 외부 라이브러리의 버전을 추적 하려면 maven (또는 ant 빌드의 경우 Ivy )을 사용하십시오. 조직 내에서 백업 된 저장소의 미러를 실행하여 항상 종속성을 제어 할 수 있도록해야합니다. 이것은 당신에게 두 세계의 장점을 제공해야합니다. 프로젝트 외부의 외부 jar이지만 여전히 안정적으로 사용 가능하고 중앙에서 액세스 할 수 있습니다.


답변

소스 코드를 확인하고 빌드 스크립트를 실행하여 프로젝트를 빌드 할 수 있기를 원하기 때문에 라이브러리를 소스 제어에 저장합니다. 최신 정보를 얻고 한 단계로 빌드 할 수없는 경우 나중에 문제가 발생할뿐입니다.


답변

타사 바이너리를 소스 제어에 저장하지 마십시오. 소스 제어 시스템은 동시 파일 공유, 병렬 작업, 병합 작업 및 변경 내역을 지원하는 플랫폼입니다. 소스 제어는 바이너리 용 FTP 사이트가 아닙니다. 타사 어셈블리는 소스 코드가 아닙니다. SDLC 당 두 번 정도 변경됩니다. 작업 공간을 깨끗하게 정리하고 소스 제어에서 모든 것을 끌어 내고 빌드하려는 욕구가 타사 어셈블리가 소스 제어에 갇혀 있어야 함을 의미하지는 않습니다. 빌드 스크립트를 사용하여 배포 서버에서 타사 어셈블리 가져 오기를 제어 할 수 있습니다. 특정 타사 구성 요소를 사용하는 응용 프로그램의 분기 / 버전을 제어하는 ​​것이 걱정되는 경우 빌드 스크립트를 통해서도 제어 할 수 있습니다. 사람들은 Java 용 Maven을 언급했으며 .Net 용 MSBuild를 사용하여 유사한 작업을 수행 할 수 있습니다.


답변

나는 일반적으로 저장소에 저장하지만 크기를 줄이려는 당신의 바람에 동정합니다.

리포지토리에 저장하지 않으면 어떻게 든 아카이브 및 버전 관리가 필요하며 빌드 시스템은이를 가져 오는 방법을 알아야합니다. Java 세계의 많은 사람들이 종속성을 자동으로 가져 오기 위해 Maven을 사용하는 것처럼 보이지만 저는 사용하지 않았으므로 실제로 권장하거나 반대 할 수 없습니다.

한 가지 좋은 옵션은 타사 시스템의 별도 저장소를 유지하는 것입니다. Subversion을 사용하는 경우 Subversion의 외부 지원을 사용하여 다른 저장소에서 라이브러리를 자동으로 체크 아웃 할 수 있습니다. 그렇지 않으면 빌드 시스템이 요구 사항을 자동으로 가져올 수있는 내부 익명 FTP (또는 유사한) 서버를 유지하는 것이 좋습니다. 분명히 모든 이전 버전의 라이브러리를 유지하고 저장소와 함께 모든 라이브러리를 백업하고 싶을 것입니다.


답변

내가 가진 것은 모든 타사 라이브러리가 저장된 인트라넷 Maven과 같은 저장소입니다 (라이브러리뿐만 아니라 문서, Javadoc 및 모든 것이 포함 된 해당 소스 배포). 그 이유는 다음과 같습니다.

  1. 변경되는 파일을 관리하도록 특별히 설계된 시스템에 변경되지 않는 파일을 저장하는 이유는 무엇입니까?
  2. 그것은 체크 아웃을 극적으로 고정
  3. 소스 제어하에 저장된 “something.jar”를 볼 때마다 “어떤 버전입니까?”라고 묻습니다.