Kho lưu trữ rất lớn với SCM nhựa

Question

Chúng tôi đang nghiên cứu SCM nhựa có thể thay thế cho Subversion để kiểm soát phiên bản với các sản phẩm của chúng tôi. Chúng tôi có một số lượng rất lớn các tài sản nhị phân (chủ yếu là các tài sản nghệ thuật, nhưng cũng bao gồm một số tài liệu, AVI, vv) ngoài một cơ sở mã nguồn rất lớn. Chỉ cần để đặt một số trên đó - một thanh toán svn của bản sửa đổi CHÍNH của chúng tôi của chi nhánh thân cây mất một ít hơn một giờ và có kích thước trên đĩa ~ 9 GB.

Có ai có kinh nghiệm với SCM nhựa trong môi trường như vậy không, hoặc có thể giới thiệu cho tôi một số giấy tờ hoặc nghiên cứu điển hình về vấn đề hiệu suất của Nhựa SCM và xử lý kho lưu trữ lớn? Googling đã không thực sự biến nhiều trong cách nghiên cứu khách quan - chỉ là công cụ được xuất bản bởi Codice mình. Tôi cũng nhận ra rằng Perforce hoạt động rất tốt trong môi trường này - tôi đã sử dụng nó trước đây - nhưng chúng tôi là một nhóm khá nhỏ, với ngân sách nhỏ, và Codice cung cấp hệ thống này miễn phí cho các nhóm nhỏ ("Community Edition").

Tôi rất gần với việc cài đặt nó trên máy chủ thử nghiệm và dùng thử ... nhưng trước hết muốn đăng câu hỏi, để không lãng phí thời gian nếu ai đó đã thử nó trong môi trường như vậy . Cảm ơn trước cho thời gian của bạn.

CẬP NHẬT 02-FEB-2011: Chỉ cần cập nhật trong trường hợp bất kỳ ai khác có câu hỏi tương tự và đang xem ... Tôi đã cài đặt Nhựa trên máy Windows 2008 Server khá khiêm tốn (2.8GHz Core 2 Duo, RAM 4 GB, kho lưu trữ được lưu trữ trên SAN trên mạng cục bộ) chạy SQL Server 2008 R2 cho các kho lưu trữ Nhựa. Việc nhập lịch sử sửa đổi subversion mất một thời gian - chỉ dưới ba ngày - ~ 28000 bản sửa đổi. Tuy nhiên, nó là SMOKIN ' nhanh để thực hiện thanh toán mới cho chi nhánh mới từ Nhựa - chỉ cần nhút nhát 4 phút bằng Nhựa so với hơn một giờ trên Subversion như được mô tả ở trên. Chúng tôi rất ấn tượng cho đến nay!

Answer 1

Chúng tôi đang chuyển mình từ Perforce sang Plastic và kho lưu trữ của chúng tôi là khoảng 360Gb, quá lớn. Nó thực sự làm việc liên tục ngay cả khi sử dụng các tập tin HUGE.

Vì chúng tôi đang trong ngành trò chơi điện tử, tệp lớn là phải, và là bạn biết tất cả các DVCS khác (Hg, Git) đều gặp sự cố khi xử lý chúng.

Answer 2

Đối với các kho lưu trữ lớn, các tùy chọn tốt nhất là MySQL hoặc SQL Server.

Firebird sẽ không mở rộng tốt với kích thước đó.