TFS 분기 및 디스크 공간

Question

나는 일부 분기 전략 (우리가 소규모 그룹이기 때문에 개발자 당 지점을 만들기)에 대해 생각해 왔으며 누군가가 어떤 문제를 경험했는지 궁금해하고있었습니다. 지점을 만드는 것이 많은 공간을 차지합니까?

Answer 1

내가 마지막으로 보았을 때, TFS는 복사기 쓰기를 사용하므로 파일을 변경할 때까지 디스크 공간을 늘리지 않을 것입니다. 상황을 바꿔야 할 때까지 Symlinks를 사용하는 것과 같습니다.

Answer 2

제임스는 기본적으로 정확합니다. 보다 완전한 답변을 얻으려면 2006 년부터 Buck의 게시물부터 시작해야합니다. http://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx

로컬 버전 테이블의 각 새 행에는 약 520 바이트가 추가됩니다 (새로 추가 된 항목을 가져 오는 각 작업 공간에 대해 한 행이 추가되고 크기는 로컬 경로 열에 의해 지배됩니다). 새로 추가 된 항목을 얻는 100 개의 작업 공간이있는 경우 데이터베이스는 52KB 증가합니다. 평균 크기의 1,000 개의 새 파일 (소스 파일, 바이너리, 이미지 등의 혼합)을 추가하고 100 개의 작업 공간을 가져 오면 버전 제어 데이터베이스는 약 112MB (60 KB * 1,000 + 520 * 1,000 * 100) 증가합니다. .

분기 항목이 파일 내용을 복제하지 않으므로 60kb 그림을 생략 할 수 있습니다. 제임스-제임스 (James)-오 (n) 양의 메타 데이터 양은 분기 작업 자체 중에 계산되고 저장되어야합니다. 새 항목이 편집 될 때까지 소스 항목과 같은 TBL_Content에서 동일한 레코드를 가리키는 것이 맞습니다). 그것은 단지 우리를 만난다 520 * num_workspaces * files_per_workspace 요인. MS Dogfood Server에는 TBL_LocalVersion에는 20 억 개의 행이 있지만 자체적으로 설명 된 소그룹에서는 완전히 무시할 수 있어야합니다.

Buck의 블로그가 언급하지 않은 것은 병합 역사입니다. 분기가 많은 워크 플로를 채택하고 여러 개발주기를 통해이를 고수하면 tbl_mergehistory가 tbl_localversion만큼 커질 것입니다. 다시 말하지만, 나는 그것이 작은 팀의 레이더에 등록 될지도 모르지만 대규모 설치에서는 수억 행을 쉽게 모을 수 있습니다. 즉, Nvarchar (260) 필드가 없기 때문에 각 행은 훨씬 작습니다.