다중 GB SVN 저장소를 Git으로 이동

현재 우리 회사는 SVN 저장소에 Visual Studio 솔루션을 가지고 있으며 다음과 같이 구성되어 있습니다.

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1과 Tool2는 독립적으로 빌드되지만 (자체 솔루션이 있음) 기본 빌드에서 사용되는 실행 파일을 생성합니다. ThirdParty 폴더에는 사전 컴파일 된 100+ MB .lib 파일 및 부스트와 같은 큰 라이브러리를 포함하여 프로젝트에 대한 모든 종속성이 포함되어 있습니다.

하나의 SVN 저장소에 모든 것을 두는 것이 편리하므로 (1) 개발자는 한 번의 체크 아웃 만 수행하면되며 (2) 각 버전의 빌드에 필요한 종속성 버전을 추적 할 필요가 없습니다. 반대로,이 저장소를 확인하는 데 시간이 걸립니다.

이 프로젝트 구조를 git으로 옮기는 가장 좋은 방법은 무엇입니까? 아마도 주요 리포지토리에서 ThirdParty 및 가능한 도구를 제외하는 것이 가장 좋지만, 한 번에 ThirdParty를 쉽게 다운로드 할 수 있도록 유지하고 싶습니다.

이 시점에서 나는 역사 보존에 관심이 없으며, 그러한 프로젝트를 조직하는 방법을 알아내는 데 관심이 있습니다.

작업에 적합한 도구를 사용하십시오. Windows에서 이는

타사 종속성에 NuGet 사용

이렇게하면 타사 종속성을 버전이 지정된 방식으로 유지하지만 불필요한 저장소로 저장소를 팽창 시키지는 않습니다. 체크 아웃이 훨씬 빨라지고 프로젝트가 정상적으로 구성됩니다. Visual Studio에서 옵션을 사용하도록 설정하면 항상 모든 종속성을 자동으로 다운로드합니다.

물론 git (또 다른 저장소, 하위 모듈 등)을 사용하는 솔루션을 사용할 수는 있지만 해킹 일뿐입니다. 올바른 방법을 사용하면 빨리 보상을 받고 미래를 대비 한 시스템을 유지할 수 있습니다.

주석 후 편집 : NuGet을 사용하는 가장 좋은 방법은 공유 드라이브 또는 전체 Nuget 서버에서 로컬 NuGet 소스를 설정하는 것입니다. 설치는 몇 분 이상 걸리지 않아야합니다. 이렇게하면 필요한 모든 패키지가 언제 어디서나 항상 사용 가능하다는 것을 보장 할 수 있습니다.

도구에 서브 모듈 을 사용할 수 있습니다 . 그렇게하면 지금하는 것처럼 서브 디렉토리에 보관할 수 있고 버전을 지정할 때 별도의 저장소를 사용할 수 있습니다. 또한 도구를 복제 (체크 아웃)하고 개별적으로 개발할 수 있으며 다른 프로젝트는 해당 저장소와 특정하고 업데이트 가능한 특정 버전에 의존 할 수 있습니다.

타사 라이브러리에 하위 모듈을 사용할 수도 있지만 가능하면 종속성 관리자를 사용하는 것이 좋습니다.

자식 리포지토리로 전환하는 엔터티는 반드시 버전 관리 및 분기 한 엔터티입니다. SolutionFolder/Tools/Tool1그런 것 중 하나에 해당 한다면 , 그것은 실체의 수준입니다. 자식이를 위해 (심지어 안 좋은 아이디어 경우) SVN으로이 가능, 반면 버전 지정 엔티티로 디렉토리 트리의 전체 상태를 간주하기 때문입니다 trunk, branches그리고 tags어디서나 나무에서.

파생 된 인공물은 저장소에 보관하거나 외부 라이브러리에 보관해서는 안됩니다. 그것들을 처리하는 더 좋은 방법이 있습니다. (Java로 작업하는 경우 개인 Maven 저장소 사용을 고려하십시오. 비교적 작업하기 쉽고 다른 많은 것들과 훌륭하게 통합됩니다.)

한 번의 리포지토리로 모든 것을 쉽게 처리 할 수있는 워크 플로에 익숙한 경우 대신 설정하는 스크립트를 사용하는 것이 좋습니다.

솔직히 말해서 나는 당신의 설정에서 아무것도 바꾸지 않을 것입니다. 바로 우리가 지금하고있는 일입니다. 우리가 사용하는 타사 라이브러리를 처리하기 위해 별도의 git 리포지토리를 설정하면서 놀고 있었지만 이식성 비용까지는 무게가 있다고 생각하지 않습니다. 이제 모든 개발자는 수동 설정 단계를 수행하지 않고도 체크 아웃하고 시작할 수 있습니다. 그리고 나는 모든 빌드 서버 / 슬레이브가 프로젝트를 빌드 할 수 있습니다. 타사 도구를 공유하는 다중 저장소가 없으면 현재 설정을 그대로 사용합니다.

내가 가지고 노는 것은 별도의 저장소에 타사 도구를 설정하는 것이 었습니다. 그런 다음 하나의 간단한 배치 스크립트가 sha1 ref가있는 텍스트 파일을 읽고 올바른 버전을 체크 아웃했습니다. 이를 통해 프로젝트마다 다른 타사 버전을 사용할 수 있습니다. Facebook Buck 빌드 도구 에서이 아이디어를 얻었습니다. 그러나 결국 많은 개발자들이 커맨드 라인 도구 (MS VC shop here)를 사용하는 것을 좋아하지 않으므로 아이디어를 포기했습니다.

NuGet을 사용하여 필요할 때 타사 라이브러리를 다운로드하지 않는 주요 이유 중 하나는 제품을 오랫동안 지원해야하기 때문입니다. 우리 업계에서는 오래된 타사 라이브러리에 의존하는 이전 버전에 대한 업데이트를 언젠가 제공해야합니다. 업그레이드 할 수있는 라이브러리를 정렬하는 데 많은 시간을 소비하지 않고 해당 버전에서 사용 된 라이브러리를 사용합니다. 이제 NuGet을 사용한다고 상상해보십시오 ... 필요한 최신 lib 버전은 3.98이지만 2.04가 필요합니다 ..... 이전 버전을 업그레이드하기 위해 2 개월을 소비해야한다고 상사에게 설명하는 방법 작은 변화를 기대할 때 최신 라이브러리를 사용하십시오!