Thực hành tốt nhất cho một dự án SVN lớn duy nhất

Question

Tôi đã kế thừa một dự án duy nhất trong svn: 30Gb trong hơn 300 000 tệp. Có rất nhiều tệp nhị phân trong đó chủ yếu nằm trong thư mục hình ảnh. Các hoạt động như cập nhật toàn bộ dự án có thể chậm đáng kể.

Nhóm nghiên cứu đã phát triển một quy trình chỉ chạy cập nhật/chuyển đổi trên các thư mục cụ thể mà họ đang làm việc và kết thúc kiểm tra mã bị hỏng vì "nó hoạt động trên máy tính của tôi". Bản sao làm việc của một người có thể bao gồm mã lỗi thời, mã chuyển đổi và mã bị quên không bao giờ cam kết. Ngoài ra, phân nhánh tối thiểu diễn ra.

Giải pháp cá nhân của tôi là một bash checkout/xây dựng kịch bản nhỏ lúc 5 giờ sáng mỗi sáng, tuy nhiên không phải ai cũng có can đảm dòng lệnh để sao chép giải pháp của tôi và thay vào đó là sự thoải mái của rùa svn và quá trình bị hỏng.

Có ai đã cố gắng điều chỉnh một kho lưu trữ lớn như vậy và có thể đưa ra lời khuyên không? Có bất kỳ phương pháp hay nhất nào tôi có thể triển khai để làm việc với các kho lưu trữ lớn mà tôi có thể giảm bớt mọi người vào không?

P.S. bên ngoài dường như không phải là ý tưởng hay và SVN optimizations to keep large repositories responsive không áp dụng ở đây vì tôi đang xử lý một dự án duy nhất

P.P.S. Điều này hiện đang được xem xét: http://www.ibm.com/developerworks/java/library/j-svnbins.html

Answer 1

Thứ nhất, nâng cấp lên SVN 1.6 trên cả máy khách và máy chủ. Ghi chú latest release đề cập đến tăng tốc cho các tệp lớn (r36389).

Thứ hai, điều này có thể không phù hợp với bạn nếu bạn phải có toàn bộ dự án trong bản sao làm việc của mình, nhưng sử dụng sparse directories. Chúng tôi làm điều này cho repo lớn của chúng tôi, điều đầu tiên một khách hàng làm là để kiểm tra các thư mục cấp cao nhất, sau đó để có được nhiều dữ liệu hơn, sử dụng trình duyệt kho để đi đến thư mục mong muốn và "cập nhật để sửa đổi này" trên đó. Nó hoạt động tuyệt vời trên TortoiseSVN. 1.6 cũng có tùy chọn 'giảm độ sâu' để xóa các thư mục mà bạn không cần phải thực hiện nữa.

Nếu điều này không phù hợp với bạn, bạn vẫn có thể cập nhật trên các phần của bản sao làm việc. Bản cập nhật có xu hướng làm chậm các tệp bạn có nhiều hơn (trên Windows có nghĩa là, NTFS có vẻ đặc biệt kém với chiến lược khóa được sử dụng để cập nhật Bert Huijben noticed this và đề xuất sửa chữa - TBA với bản phát hành 1.7, nhưng bạn có thể xây dựng lại mã hiện tại của mình 'sửa chữa nhanh chóng' của mình

Một thay thế có thể là thay đổi hệ thống tập tin của bạn, nếu bạn có thể định dạng, bạn có thể thử các ext2 IFS driver, nhưng tôi chắc chắn bạn sẽ phải thận trọng về điều đó

tùy chọn cuối.! - tắt máy quét virus của bạn cho .svn firectories, và cũng cho các kho lưu trữ trên máy chủ.Nếu bạn đang chạy Apache trên máy chủ, hãy chắc chắn rằng bạn đã giữ cho alives trong một thời gian ngắn (để ngăn chặn tái xác thực từ xảy ra). Đồng thời tắt tính năng lập chỉ mục trên các thư mục sao chép hoạt động của bạn và bản sao bóng quá. (cuối cùng không giúp được nhiều, nhưng bạn có thể thấy một cải tiến tốt hơn mà tôi đã làm, tắt AV trên máy chủ đã tăng gấp 10 đáp ứng SVN của tôi).

Answer 2

Để xử lý kích thước khó sử dụng, tôi xem xét tách dữ liệu nhị phân thành một nhánh khác (hoặc thậm chí xóa hoàn toàn dữ liệu đó ở nơi khác), tách biệt với mã. Điều này ít nhất phải tăng tốc độ, đặc biệt nếu dữ liệu không thay đổi thường xuyên.

Tôi hiểu nhu cầu mọi người có vị trí trung tâm cho các công cụ, dữ liệu và thư viện của họ, nhưng nó không hoạt động tốt khi có một bãi chứa.

Answer 3

Tôi là người quản lý SCM trong tình huống tương tự. Chúng tôi đã có một dự án với hơn 200 nghìn tệp (chủ yếu là mã) có một số vấn đề tương tự. Giải pháp của chúng tôi là chia tách kho thành hai phiên bản. Một phiên bản là phiên bản phát triển và phiên bản còn lại là phiên bản sản xuất. Chúng tôi đưa ra phiên bản phát triển với bản sao làm việc mới nhất và nổi tiếng nhất của tất cả các mã. Khi họ cảm thấy mọi thứ ổn định, một quản trị viên (trong trường hợp của chúng tôi là người quản lý xây dựng) đã hợp nhất mã và đã xây dựng thử nghiệm để xác minh mọi thứ đã hoạt động chính xác. Nếu mọi thứ trôi qua thì tốt. Nếu không phải người quản trị xây dựng sẽ săn lùng nhà phát triển và trừng phạt họ nghiêm trọng. Chúng tôi đã có một số vấn đề tương tự trong phần đầu, nơi "Nó hoạt động trên máy tính của tôi", v.v., nhưng trước khi chúng được thực hiện nhờ đánh đập và phát tán .....

Tại các điểm cụ thể mã phát triển (TẤT CẢ MÃ LÀM VIỆC !!!!) đã được sáp nhập lại vào hoạt động sản xuất và phát hành cho khách hàng.

Answer 4

Chúng tôi có hai kho, một cho mã của chúng tôi (thay đổi thường xuyên) và một cho dữ liệu nhị phân của chúng tôi (rất lớn, thay đổi không thường xuyên). Đó là một cơn đau đôi khi, nhưng giá trị tốc độ tốt hơn khi làm việc với mã.

Chúng tôi cũng có một tập lệnh Ruby mà chúng tôi gọi là "cập nhật hàng ngày", được đăng ký vào kho lưu trữ của mình. Nó cập nhật cả hai lần kiểm tra lên phiên bản mới nhất, sau đó xây dựng mọi thứ cục bộ, vì vậy chúng tôi đã sẵn sàng để đi ngay khi chúng tôi đến vào buổi sáng.

Có một số trục trặc mà chúng tôi chưa đưa ra - ví dụ: khi thử nghiệm tự động của chúng tôi chạy, hiện tại có sự chậm trễ khi kiểm tra mã và khi họ kiểm tra dữ liệu, khi chúng tôi cam kết thay đổi cho cả hai kho lưu trữ, máy chủ CI đôi khi nhận được mã cũ và dữ liệu mới, gây ra lỗi kiểm tra.

Khi chúng tôi thực hiện thay đổi đối với kho dữ liệu, chúng tôi thường chỉ cho mọi người biết họ cần cập nhật (tất cả chúng ta đều ngồi trong cùng một phòng). Nếu không, chúng tôi thường không cập nhật dữ liệu theo cách thủ công; chúng tôi chỉ để kịch bản cập nhật hàng ngày giữ cho nó luôn mới mẻ.

Answer 5

Có thể chia dự án thành các dự án nhỏ hơn có thể được kết nối thông qua một số loại hệ thống plugin không?

Answer 6

Tôi sẽ giữ nó ngắn gọn:

• Nâng cấp lên phiên bản mới nhất (1.6.x). 1.5.x cũng có tối ưu tốc độ.
• Đảm bảo mọi người đang sử dụng cùng phiên bản TortoiseSVN được xây dựng dựa trên phiên bản chính xác của máy chủ. Chúng tôi đã có nhiều vấn đề với những người cập nhật trên whim và sau đó nhận được những vấn đề lạ.
• Externals hoạt động giữa các máy chủ, kho lưu trữ và thư mục trên cùng một repo. Vì vậy, bạn có thể có thể di chuyển các tệp nhị phân sang một máy chủ/máy chủ khác hoàn toàn và chỉ liên kết với chúng bằng các phần tử bên ngoài.
• Tái cấu trúc các thư mục để bạn có thể kiểm tra dự án thưa thớt và vẫn có thể hoạt động hiệu quả. Về cơ bản tất cả mọi người kiểm tra ra thư mục tops + trẻ em chỉ sau đó chọn lọc "cập nhật để sửa đổi" các thư mục mà họ cần phải kiểm tra đầy đủ.
• Tạo các tập lệnh xuất, xây dựng rồi cam kết (hoặc nhắc thực hiện). Tôi có các kịch bản như vậy để sử dụng. Trước khi cam kết, tôi chạy kịch bản và nó xuất khẩu wc của tôi và sau đó xây dựng. LƯU Ý: Điều này sẽ sao chép toàn bộ wc!Vì vậy, điều này hữu ích khi kiểm tra thưa thớt nơi kích thước dữ liệu nhỏ (er).
• Cân nhắc di chuyển các tệp nhị phân ra khỏi repo (Tôi không khuyến nghị điều này, nhưng nó có thể là giải pháp an toàn nhất để tăng năng suất lại).
• Hãy nhớ rằng, việc xuất không tạo ra wc, điều đó có nghĩa là bạn tiết kiệm được 50% dung lượng đĩa so với các lần kiểm tra. Vì vậy, nếu bạn tái cấu trúc các tập tin nhị phân đó và các mục được cập nhật không thường xuyên có thể được xuất thay vì thanh toán, nó sẽ khuyến khích nhiều người hơn "nhận được đầy đủ" và không cố gắng đọc lướt qua nó.