Subversion을 아티팩트 저장소로 사용 및 특정 아티팩트 관리 도구

TL; DR : 왜 Apache Archiva 또는 Sonatype Nexus 와 같은 것을 Subversion 대신 아티팩트 저장소로 사용합니까?

내가 사용하는 빌드 시스템에는 현재 빌드에 대한 입력 및 출력으로 많은 이진 블로 브 (이미지, 사운드 파일, 컴파일 된 이진 등)가 있습니다. 이러한 관리 시스템은 매우 특별합니다. 일부는 코드와 함께 Subversion 저장소에 체크인되고 일부는 공식 버전 제어 외부에 저장됩니다.

나는 이것을 통합하려고합니다. 그래서 우리는 더 일관성 있고 사용하기 쉽고 바이너리 아티팩트를 코드와 분리시키는 것을 가지고 있습니다.

Google은 사용 가능한 아티팩트 리포지토리 ( Archiva , Nexus , Artifactory 등)가 있다고 말하지만 주변에서 읽을 때 Subversion보다 이러한 이점을 사용할 때 이점을 볼 수 없습니다. 이진은 우리를 위해 바이너리를 돌보게 될 것입니다. 이미 일부 바이너리에 대해서는 리포지토리 레이아웃을 코드와 분리하기 위해 재배치하고 싶었습니다. 이미 서브 버전 서버와 전문 기술을 보유하고 있다는 주목할만한 이점이 있습니다.

그래서. Subversion과 같은 일반적인 버전 관리 도구를 사용하는 것보다 전용 아티팩트 관리 시스템을 사용하는 것의 장점은 무엇입니까?

짧은 대답 : 일반적으로 바이너리 아티팩트의 히스토리와 해당 아티팩트의 변경이 필요하지 않으며 특정 버전 만 필요합니다.

더 긴 대답 : 이진 파일을 약간 변경하면 버전 제어 시스템은 두 파일 사이의 차이 인 델타를 만들 방법이 없으므로 완전히 새로운 사본을 만듭니다.

SVN과 같은 CVCS에서는 저장소의 중앙 사본이 하나뿐이므로 로컬 사본은 하나의 버전이기 때문에 그리 큰 문제는 아닙니다. (그렇더라도 저장소가 매우 커져 체크인 속도가 느려질 수 있습니다.) 나중에 DVCS로 전환하면 저장소의 모든 사본에 모든 파일의 전체 히스토리가있는 경우 어떻게됩니까? 변경의 크기는 매우 관련성이 있습니다.

그리고 고통에 대한 대가로 무엇을 제공합니까? 그것이 제공하는 유일한 것은 이전 버전의 저장소로 돌아가서 해당 버전에 대한 올바른 바이너리가 있음을 알고 있다는 것입니다.

그러나이를 수행하려면 저장소에 전체 바이너리가 필요합니까? 아니면 다른 저장소에서 다른 버전을 가져올 빌드 프로세스를 알려주는 텍스트 파일 만 있으면됩니다.

후자는 일반적으로 아티팩트 저장소에서 제공하는 것입니다.

또한 Nexus와 같은보다 전문적인 제품 중 일부는 타사 아티팩트에 대한 라이센스 정보도 제공하므로 FOSS 라이브러리라고 생각하는 내용에 대한 미묘한 조항에 위배 될 위험이 없습니다.

우리는 SVN을 릴리스 빌드의 저장소로 사용하며 매우 잘 수행됩니다. 우리는 하나의 릴리스 저장소에 30gb의 다양한 릴리스 빌드보다 우수하며 배포를 위해 빌드를 잘 수행합니다.

이 작업의 장점 중 일부는 ..

• SVN에 추가 된 바이너리는 평균 저장 공간에서 거의 60-70 % 압축됩니다.
• SVN은 릴리스를위한 라이브러리 (아티팩트) 역할을하며 저장소는 재해 복구 목적으로 백업됩니다.
• https를 통한 SVN을 통해 릴리스 코드를 DMZ로 안전하게 전달할 수 있습니다.