TFS Branching and Disk Space

Question

Tôi đã suy nghĩ về một số chiến lược phân nhánh (tạo chi nhánh cho mỗi đối tượng, có thể cho mỗi nhà phát triển vì chúng tôi là một nhóm nhỏ) và tự hỏi liệu có ai gặp bất kỳ vấn đề nào không. Việc tạo chi nhánh có chiếm nhiều không gian?

Answer 1

Lần cuối cùng tôi xem, TFS sử dụng sao chép-ghi-ghi, điều đó có nghĩa là bạn sẽ không tăng dung lượng ổ đĩa cho đến khi bạn thay đổi tệp. Nó giống như sử dụng các liên kết tượng trưng cho đến khi bạn cần thay đổi mọi thứ.

Answer 2

James về cơ bản là chính xác. Đối với một câu trả lời hoàn chỉnh hơn, chúng ta cần phải bắt đầu với bài Buck từ phía sau vào năm 2006: http://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx

Mỗi hàng mới trong bảng phiên bản địa phương cho biết thêm khoảng 520 byte (một hàng được thêm vào cho mỗi không gian làm việc mà được sự mới được bổ sung mục và kích thước bị chi phối bởi cột đường dẫn cục bộ). Nếu bạn có 100 không gian làm việc để có được mục mới được thêm vào, cơ sở dữ liệu sẽ tăng 52 KB. Nếu bạn thêm 1.000 tệp mới có kích thước trung bình (kết hợp tệp nguồn, tệp nhị phân, hình ảnh, v.v.) và có 100 không gian làm việc, chúng sẽ tăng khoảng 112 MB (60 KB * 1,000 + 520 * 1.000 * 100) .

Chúng tôi có thể bỏ qua số 60KB vì các mục được phân nhánh không trùng lặp nội dung tệp. (Nó không hoàn toàn "copy-on-write", James - một số lượng siêu dữ liệu O (N) phải được tính toán và lưu trữ trong quá trình hoạt động nhánh, so với các hệ thống như git mà tôi tin rằng chi nhánh trong O (1) - nhưng bạn đúng là mục mới trỏ đến cùng một bản ghi trong tbl_Content làm mục nguồn cho đến khi nó được chỉnh sửa). Điều đó khiến chúng ta chỉ đơn thuần là yếu tố 520 * num_workspaces * files_per_workspace. Trên máy chủ dogfood MS có một cái gì đó giống như 2 tỷ hàng trong tbl_LocalVersion, nhưng trong một nhóm nhỏ được mô tả tự nó nên hoàn toàn không đáng kể.

Blog của Buck nào đó không đề cập đến là lịch sử hợp nhất. Nếu bạn áp dụng một luồng công việc nặng nhọc và gắn bó với nó thông qua một số chu kỳ phát triển, có khả năng tbl_MergeHistory sẽ phát triển gần như lớn như tbl_LocalVersion. Một lần nữa, tôi nghi ngờ nó thậm chí sẽ đăng ký trên radar của một nhóm nhỏ, nhưng trên các cài đặt lớn, bạn có thể dễ dàng tích lũy hàng trăm triệu hàng. Điều đó nói rằng, mỗi hàng nhỏ hơn nhiều vì không có trường nvarchar (260).