자식으로 이동할 때 큰 svn 기록에 대해 어떻게해야합니까?


23

편집 : 다중 GB SVN 저장소를 Git 또는 /programming/540535/managing-large-binary-files-with-git이동하는 것과 같은 유사한 질문과 달리 내 시나리오에는 여러 하위 프로젝트가 포함되지 않습니다. git submoduels 또는 git-annex에 적합한 매우 큰 바이너리 파일로 쉽게 변환 할 수 있습니다. 바이너리가 테스트 스위트 인 단일 리포지토리이며, 그래픽과 같은 컴파일 타임 자산과 마찬가지로 동일한 개정의 기본 소스 코드에 밀접하게 결합되어 있습니다.

svn에서 오래된 중형 / 대형 (50 명의 사용자, 60k 개정, 80Gb 기록, 2Gb 작업 사본) 코드 저장소를 전환하는 방법을 조사 중입니다. 사용자 수가 늘어남에 따라 트렁크에 많은 변화가 발생하고 코드 검토가 어려운 여러 커밋에 기능이 퍼지는 경우가 많습니다. 또한 분기없이 잘못된 코드를 "게이트"할 수있는 방법이 없으며 트렁크에 커밋 한 후에 만 검토를 수행 할 수 있습니다 . 대안을 조사 중입니다. 우리가 자식으로 이동할 수 있기를 바랐지만 몇 가지 문제가 있습니다.

git가 진행되는 한 현재 저장소의 문제는 크기입니다. 거기에 오래된 균열이 많이 있으며, git로 변환 할 때 --filter-branch로 청소하면 크기를 5-10GB 정도로 줄일 수 있습니다. 이것은 여전히 ​​너무 큽니다. 저장소 크기가 큰 가장 큰 이유는 테스트에 입력 할 바이너리 문서가 많기 때문입니다. 이 파일은 0.5MB와 30MB 사이에서 다양하며 수백 가지가 있습니다. 또한 많은 변화가 있습니다. 나는 서브 모듈, git-annex 등을 살펴 보았지만 서브 히스토리에서 테스트를하는 것은 잘못된 느낌입니다. 전체 히스토리를 원하는 많은 파일에 대한 부록이있는 것처럼.

따라서 git의 분산 특성은 실제로 그것을 채택하지 못하게 막는 것입니다. 나는 실제로 분산에 관심이 없으며 저렴한 분기 및 강력한 병합 기능을 원합니다. git 사용자의 99.9 %가 가정하는 것처럼, 우리는 축복받은 베어 중앙 저장소를 사용합니다.

git을 사용할 때 각 사용자가 전체 로컬 히스토리를 가져야하는 이유를 잘 모르겠습니다. 워크 플로가 분산되지 않은 경우 해당 데이터가 사용자 디스크에서 수행하는 작업은 무엇입니까? 최신 버전의 git에서는 최근 기록 만 사용하는 얕은 클론을 사용할 수 있다는 것을 알고 있습니다. 내 질문은 : 전체 팀의 표준 운영 모드 로이 작업을 수행 할 수 있습니까? git을 항상 얕게 구성하여 전체 기록을 중앙에서만 사용할 수 있지만 기본적으로 사용자는 1000 개정의 기록 만 가질 수 있습니까? 물론 옵션은 1000 rev를 git로 변환하고 svn repo를 고고학으로 유지하는 것입니다. 그러나이 시나리오에서는 테스트 문서를 다음 수천 번 수정 한 후에도 같은 문제가 다시 발생합니다.

  • 당신이 많은 바이너리 파일을 포함하는 대규모의 repos와 자식을 사용하기위한 좋은 가장 좋은 방법은 무엇입니까 않습니다 에 대한 역사를 원하는가? 대부분의 모범 사례와 자습서는이 경우를 피하는 것 같습니다. 그들은 몇 개의 거대한 바이너리의 문제를 해결하거나 바이너리를 완전히 떨어 뜨릴 것을 제안합니다.
  • 얕은 복제는 정상 작동 모드로 사용할 수 있습니까? 아니면 "해킹"입니까?
  • 메인 소스 리비전과 서브 모듈 리비전 사이에 밀접한 관계가있는 코드에 서브 모듈을 사용할 수 있습니까 (예 : 컴파일 타임 이진 종속성 또는 단위 테스트 스위트에서)?
  • git 저장소 (온-프레미스)의 "너무 큰"크기는 얼마입니까? 4GB로 줄일 수 있다면 전환을 피해야합니까? 2GB?


나는 이것에 대한 정보를 많이 찾았지만 내 질문에 대답하는 것을 찾지 못했습니다. 관련 질문에서 workaounrds (서브 모듈, 부속서 등)는 내 시나리오보다 훨씬 잘 작동합니다.
Anders Forsgren 7


Perforce는 많은 이진 파일을 처리하도록 설계되었으므로 많은 게임 개발자가 사용하기 때문에 git보다 나은 옵션입니다. Plasticscm도 볼 가치가 있습니다.
Ian

단지 옆으로 : git 서브 모듈은 빌드 시스템을 복잡하게 만들기 때문에 가능하다면 git 서브 모듈을 피하십시오 (이미 귀하의 경우에는 복잡합니다).
IgorGanapolsky

답변:


10

와우, 그것은 긴 질문 (그리고 복잡한 문제)입니다. 나는 그것에 가려고 노력할 것이다.

git을 사용할 때 각 사용자가 전체 로컬 히스토리를 가져야하는 이유를 잘 모르겠습니다.

이것은 git의 중심 디자인 결정입니다. 정확한 이유 때문에 저자 (Linus Torvalds)에게 문의해야하지만, 내가 아는 한, 주된 이유는 속도입니다. 모든 로컬 디스크 (빠른 디스크 또는 RAM에 캐시 됨)를 사용하면 기록 작업이 훨씬 빨라집니다 네트워크 액세스를 피함으로써.

저장소 크기가 큰 가장 큰 이유는 테스트에 입력 할 바이너리 문서가 많기 때문입니다. 이 파일은 0.5MB와 30MB 사이에서 다양하며 수백 가지가 있습니다. 또한 상당히 많은 변화가 있습니다.

그것이 내가 먼저 생각할 요점입니다. 소스 제어에서 지속적으로 변경되는 바이너리 파일이 너무 많으면 SVN에서도 문제가되는 것 같습니다. 다른 접근법을 사용할 수 없습니까? 아이디어 :

  • 소스 코드와 달리 3MB 이진 파일은 직접 작성하지 않았을 수 있습니다. 일부 도구 / 프로세스가 생성하는 경우 데이터를 저장하는 대신이를 빌드에 통합하십시오.

  • 이것이 실용적이지 않으면, 일반적으로 아티팩트 저장소 (예 : Artifactory for Maven & co.)에서 바이너리 파일이 더 좋습니다. 아마도 이것이 당신을위한 옵션 일 것입니다.

나는 서브 모듈, git-annex 등을 살펴 보았지만 서브 히스토리에서 테스트를하는 것은 잘못된 느낌입니다. 전체 히스토리를 원하는 많은 파일에 대한 부록이있는 것처럼.

실제로 이것은 git-annex가 완벽하게 맞는 것처럼 보입니다. git-annex는 기본적으로 git 저장소 외부에 파일 내용을 저장할 수 있습니다 (저장소에는 자리 표시자가 포함되어 있음). 파일 내용을 다양한 방법 (중앙 git repo, 공유 드라이브, 클라우드 저장소 등)으로 저장할 수 있으며 로컬로 원하는 내용을 제어 할 수 있습니다.

git-annex의 작동 방식을 이해하지 못했습니까? git-annex는 관리하는 모든 파일에 대한 전체 히스토리를 저장합니다. 로컬에서 어떤 파일 내용을 원하는지 선택할 수 있습니다.

마지막으로 귀하의 질문에 대해 :

히스토리를 원하는 많은 바이너리 파일을 포함하는 큰 저장소와 함께 git을 사용하는 가장 좋은 방법은 무엇입니까?

내 경험상 옵션은 일반적으로 다음과 같습니다.

  • 저장소에 바이너리가 필요하지 않습니다 (요청시 생성하고 다른 곳에 저장하십시오)
  • git-annex (또는 Git LFS와 같은 유사한 솔루션)를 사용하십시오.
  • 큰 저장소로 라이브하십시오 (모든 git 작업이 큰 파일의 영향을받는 것은 아니며 빠른 컴퓨터 및 드라이브가 있으면 꽤 작동 할 수 있습니다)

얕은 복제는 정상 작동 모드로 사용할 수 있습니까? 아니면 "해킹"입니까?

그것은 가능할 수 있습니다. 그러나 이것이 귀하의 문제를 해결할 것이라고 생각하지 않습니다.

  • 당신은 역사의 빠른 검색과 같은 전체 역사를 가지고 git의 이점을 잃을 것입니다
  • AKAIK에 병합하려면 분기 지점으로 돌아가는 기록이 있어야하기 때문에 병합이 까다로울 수 있습니다.
  • 사용자는 복제본의 크기를 작게 유지하기 위해 주기적으로 다시 복제해야합니다.
  • git을 사용하는 드문 방법이므로 많은 도구에 문제가 생길 수 있습니다.

git 저장소 (온-프레미스)의 "너무 큰"크기는 얼마입니까? 4GB로 줄일 수 있다면 전환을 피해야합니까? 2GB?

그것은 repo의 구조 (몇몇 / 많은 파일 등), 당신이하고 싶은 일, 컴퓨터가 얼마나 비프 고, 인내심에 달려 있습니다 :-).

빠른 아이디어를 제공하려면 : (새롭지 만 사양이 낮은) 랩톱에서 500MB 파일을 커밋하는 데 30-60 초가 걸립니다. 목록 기록 (git log 등) 만 큰 파일의 영향을받지 않습니다. 파일 내용을 스캔해야하는 "git log -S"와 같은 것들은 매우 느리지 만, 속도는 주로 I / O에 의해 좌우되므로 실제로 자식의 결함이 아닙니다.

소수의 수정본이있는 3GB 리포지토리에서 "git log -S"는 약 1 분이 걸립니다.

따라서 이상적이지는 않지만 2GB가 괜찮다고 말하고 싶습니다. 10-20GB 이상이이를 추진하고 있지만 가능할 수도 있습니다. 시도해보아야합니다.


자세한 답변에 감사드립니다. 테스트 문서에 부록을 사용하는 것을 확실히 살펴볼 것입니다. "합리적인 성능"에 대한 막대는 아마도 "svn에 가깝습니다"입니다. 즉, 어떤 작업에서 상당히 느리면 전환하기에는 너무 많은 마찰이 발생합니다.
Anders Forsgren

Git LFS는 큰 이진 파일 저장소에도 사용할 수 있다고 생각합니다.
IgorGanapolsky

@ IgorG. : 예, Git LFS는 대안입니다. 다른 것들도 있습니다. 지적 해 주셔서 감사합니다. 게시물을 수정했습니다.
sleske

4

사용자 수가 늘어남에 따라 트렁크에 많은 변화가 발생하고 코드 검토가 어려운 여러 커밋에 기능이 퍼지는 경우가 많습니다. 또한 분기가 없으면 잘못된 코드를 "게이트"하는 방법이 없으며 트렁크에 커밋 한 후에 만 ​​검토를 수행 할 수 있습니다.

git으로 이동해도 이러한 문제는 해결되지 않으며 도구 사용 방법에 문제가 있으며 git을 같은 방식으로 사용하면 문제가 남아 있습니다.

git 에서처럼 svn으로 쉽게 분기 할 수 있으며 병합은 일반적으로 쉽고 쉽고 함정이 동일합니다. Git은 커널 소스 코드와 함께 작동하도록 설계되었으므로 큰 바이너리 및 대규모 이력이있는 경우와 같이 모든 경우에 적용되지 않을 수도 있다고 가정했습니다. DVCS의 의도는 모든 사용자가 효과적으로 혼자 일하고 나중에 만 협업하는 것입니다. 즉, 자신의 저장소 (사본)가 있고 원하는 방식으로 작업 한 다음 원하는 사람에게 변경 사항을 적용합니다. 리눅스 커널 개발에 사용되는 페더 레이 티드 시스템은 이것에 완벽합니다. 체인을 코드 체인과 병합 한 다음 사람에게 변경 사항을 푸시 한 다음 릴리스에 넣은 Linus에 도달 할 때까지 다음 사람에게 변경 사항을 푸시합니다. 대부분의 팀은 git을 비슷하게 사용하지만 서버 측 '골드'리포지토리 인 업스트림 녀석은 1 명뿐입니다.

따라서 작업 방식을 먼저 변경하고 더 나은 작업 방법을 찾으면 git으로 마이그레이션하는 것을 살펴 보겠습니다. 파일이나 디렉토리의 이름을 바꾸지 않으면 SVN에서 분기 및 병합을 구현하면 병합이 잘됩니다.


4
"git 에서처럼 쉽게 svn으로 분기 할 수 있으며, 병합은 일반적으로 쉽고 간단하며 같은 함정을 가지고 있습니다." 내 의견으로는 git에서 병합하는 것은 일반적으로 산들 바람이며 svn에서는 일반적으로 병합 추적에서 반 구운 시도가 도입 된 버전에서도 악몽입니다 (예,이 레포가 아닌 git과 함께 작업합니다). 우리가 원하는 워크 플로우는 해당 브랜치에서 기능 브랜치, 코드 검토 / CI 빌드를 수행하는 워크 플로 입니다. SVN에서는 큰 좌절없이 그렇게 할 수있는 방법이 없습니다.
Anders Forsgren

2
아니, 우리는 항상 여기에 있습니다. SVN 저장소의 157 가지를 통해 삭제할 수있는 항목을 확인하려고합니다. 우리는 여기에서 거의 매일 분기하고, 개발하고, 검토 한 다음 병합하고 때로는 문제에 봉착하지만 항상 트렁크에서 새 분기를 가져 와서 변경 사항을 병합함으로써 수정됩니다 (따라서 나중에 트렁크로 쉽게 병합 할 수 있음) . 그것은 고대 지사에만 실제로 적용됩니다. 당신이 큰 좌절감을 가지고 있다면, 당신은 그것을 충분히 이해하지 못합니다. 힘내는 또한 당신에게 엄청난 좌절감을 줄 것입니다.
gbjbaanb

2
나는 그것을 경험하지 않습니다. git으로 작업 할 때 (내가 말했듯이 더 작은 repos에서) 분기, rebasing, squashing 및 merging 기능을 수행하는 것이 매우 쉽고 자연 스럽습니다. "이름 변경 후 트리 충돌"등은 훨씬 드물게 느껴지며 리베이스 + 스쿼시 등을 통해 선형적이고 간단한 기록을 에뮬레이션 할 수 있다는 사실이 매우 중요합니다. 그래서 : 주제에 대한 질문을 유지하기 위해 (큰 repos가있는 git) svn이 필요한 워크 플로를 지원하지 않는다고 가정하고 git은 수행한다고 가정합니다.
Anders Forsgren

1
이전 회사에서는 git을 사용했으며 정기적으로 작업을 잃어 버린 사람을 알고 있으므로 완벽한 시스템은 아닙니다! SVN도 아니지만 SVN은 git IMHO보다 환경에 훨씬 적합하며 작동합니다. 주제에 따라 원하는대로 git 작업을 수행하는 방법 ... 정말 확실하지 않습니다. 죄송합니다.
gbjbaanb

7
@gbjbaanb 누군가 Git과의 작업을 잃고 있다면 , 뭔가 잘못하고있는 것입니다.
RubberDuck

2

GCC 메일 링리스트를 살펴보십시오. GCC의 역사를 유지하면서 GCC 컴파일러의 소스 트리를 SVN에서 GIT로 마이그레이션하는 것이 현재 (2015 년 8 월 및 9 월) 논의됩니다. git 변환 메일 스레드에 대한 변환 기계승인 기준 의 저장소를 참조하십시오 . 변환과 관련된 도구 및 절차에 대한 참조를 찾을 수 있습니다. (직관적이지 않습니다. 큰 코드 기반 기록의 변환에는 36 시간 및 약 64GB의 RAM, IIRC가 필요합니다)


SVN에서 Git으로 마이그레이션하는 것을 의미 했습니까? 버전 제어 시스템에서 컴파일러 스위트로 마이그레이션하는 것은 약간 이상합니다. 또한 이것은 답변보다 주석과 비슷합니다.
8bittree

예. 오타가 유감입니다.
Basile Starynkevitch

감사. 산들 바람처럼 36시간 사운드는, 우리는 ... 몇 주 변환 할 수 있습니다
앤더스 Forsgren

2

복제를 실행할 수없는 것입니다 거대한 저장소에 망할 놈의 결과로 전체 SVN 저장소를 변환하는 경우에, 당신은 사용해 볼 수 있습니다 SubGit을 서브 버전 저장소의 특정 부분에 대한 작은 망할 놈의 거울을 만드는.

예를 들어, SVN 저장소의 일부 서브 디렉토리를 가져오고 동기화 할 수 있습니다 http://domain/repos/trunk/project/src.

subgit configure --layout auto --trunk trunk/project/src http://domain/repos project.git
edit project.git/subgit/config
edit project.git/subgit/authors.txt
subgit install project.git

SubGit 사용에 대한 자세한 내용은 해당 설명서를 참조하십시오 .

해당 디렉토리의 Git 미러가있는 즉시 Git 저장소를 사용하여 SVN 저장소에 즉시 반영되는 새로운 변경 사항을 제출할 수 있습니다. 변환 된 Git 저장소의 크기를 크게 줄이는 SVN 저장소의 특정 부분 만 동기화하고 분기를 생성하고 병합 할 수 있으며 Git 측의 워크 플로우를 사용할 수 있습니다.

또는 전체 SVN 저장소를 가져 오지만 동기화에서 큰 파일을 제외 할 수 있습니다.

subgit configure --layout auto --trunk trunk http://domain/repos project.git
edit project.git/subgit/config
...
[svn]
    excludePath = *.bin
    excludePath = *.iso
...
edit project.git/subgit/authors.txt
subgit install project.git

결과 Git 저장소의 크기는 합리적이어야하며 개발자는 여전히 Git을 사용하여 변경 사항을 Subversion 저장소에 제출할 수 있습니다.

Subversion 서버를 계속 실행하고 SVN 저장소와 함께 Git을 사용할 준비가 되었으면이 솔루션이 효과적입니다.

면책 조항 : 저는 SubGit 개발자 중 하나입니다. SubGit은 다양한 무료 옵션을 제공하는 상용 소프트웨어입니다.


1

나는 당신의 상황에 다음과 같은 방식으로 접근했습니다.

1) SVN 저장소와 동일한 디렉토리에서 git 저장소를 초기화하십시오. 수행 git initgit remote add origin그 자식의 repo를 시작합니다. 이렇게하면 준비가 될 때까지 서로간에 전체 변환을 처리하지 않고 SVN과 git을 계속 커밋 할 수 있습니다.

2) https://confluence.atlassian.com/bitbucket/reduce-repository-size-321848262.html에서 논의 된 것처럼 bfgfilter-branch 도구를 사용하여 git repo를 시도하고 축소하십시오.

3) git-annex 또는 Git LFS를 사용하거나 대용량 바이너리에 외부 스토리지 서버를 사용하십시오 (빌드 타임에 쉘 스크립트를 사용하여 파일 전송).

4) git repo의 병합 / 분기 전략에 익숙하고 git repo의 크기에 익숙해지면 svn에서 git으로 완전히 마이그레이션 할 수 있습니다.

이것이 도움이되기를 바랍니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.