2009-03-24 23 views

Trả lời

0

Công ty tôi đã làm việc tại Subversion sử dụng cho hàng trăm người dùng không có máy chủ của riêng họ. Thay vào đó, nó là một dịch vụ được quản lý từ Collabnet.

5
  • Chọn cấu trúc thư mục phù hợp ngay từ đầu - đó là một bitch để thay đổi sau này.
    • tôi có xu hướng nghĩ rằng "tốt nhất" được tổ chức bởi dự án, với một thân cây/thẻ/Chi nhánh theo từng dự án
  • Mỗi người không cần mỗi dự án kiểm tra ra. Chỉ kiểm tra những gì bạn cần
  • Tìm ra một số cách để chia sẻ công cụ giữa các nhà phát triển. Những điều nhỏ nhặt như một chương trình khác biệt SQL lấy procs ra khỏi máy chủ và phân biệt chúng là vô giá.
  • Cố gắng không để cho bất kỳ dự án nào quá lớn. Cố gắng cập nhật hoặc cam kết trên một thư mục với 1GB là annoyingly dài để tính
  • Hình ra một số chiến lược nâng cấp cho máy chủ lật đổ
  • sao lưu kho lưu trữ của bạn tất nhiên - với lịch sử sửa đổi đầy đủ
  • Trác rất hữu ích để liên kết người trực tiếp để thay đổi và khác biệt
  • Làm cho nó trở nên thú vị. Chạy tìm kiếm từ khóa qua repo vào cuối tuần và biểu đồ tần suất mọi người nói lời nguyền trong mã. Run a code swarm
0

Tôi đã thấy hàng trăm nhà phát triển sử dụng CVS cho hàng trăm dự án, vì vậy svn nên làm điều đó tốt. Vấn đề duy nhất tôi đã nhận thức được về không gian đĩa được sử dụng cho các thư mục làm việc và các bản sao lưu của chúng.

4

Tôi đã làm việc trên nhóm đã triển khai Subversion nội bộ lưu trữ trên 3 vị trí địa lý và hàng trăm nhà phát triển và hơn 100 dự án. Một số bài học chính

  1. Sử dụng Apache mod_svn thay vì svnserve. Sau đó, bạn có thể liên kết 'xác thực subversion' với LDAP (hoặc xác thực ActiveDirectory) cho các nhóm đó không phải nhớ thêm một loginname và mật khẩu nữa.

  2. Tạo nhiều kho lưu trữ trên cùng một máy chủ thay vì một kho lưu trữ lớn với các thư mục con khác nhau cho từng dự án. Bằng cách này, việc quản lý người dùng và kiểm soát truy cập được đơn giản hóa. Ngoài ra nhiệm vụ đóng và lưu trữ các kho lưu trữ trên dự án hoàn thành được đơn giản hóa.

  3. Chúng tôi đã phát triển các tập lệnh cgi python đơn giản để quản lý người dùng, quyền và tập lệnh svn-hook cho thông báo email và nguồn cấp dữ liệu RSS. Các kịch bản đã giúp các nhóm dự án chấp nhận svn nhanh hơn.

  4. Bạn có thể đặt proxy ngược và chọn lọc hiển thị một vài dự án qua quyền truy cập 'https' từ bên ngoài mạng công ty. Bằng cách này, các nhà cung cấp/nhà thầu bên ngoài có thể kiểm soát các dự án.

Nhìn chung, chúng tôi di chuyển tất cả các nhóm dự án trong khoảng một năm sang hệ thống mới (bao gồm di chuyển dữ liệu từ các hệ thống hiện có như CVS và Visual SourceSafe).

0

Tôi hoàn toàn đồng ý với Nitin Bhide. bổ sung của tôi:

nếu bạn sử dụng để CVS một số công việc trong SVN là rất khác nhau, ví dụ nhà cung cấp chi nhánh, đó là không tồn tại trong CVS, bởi vì bạn chỉ cần xóa tất cả các file trong thư mục nhà cung cấp và sao chép phiên bản mới bên trong. Điều này sẽ không hoạt động trong SVN nữa.

Ngoài ra nếu bạn quen với nhật thực, rất nhiều thứ trong lật đổ như trong hình con là khác nhau. Bạn nên đào tạo người dùng để làm quen với số sửa đổi toàn cầu là điểm khó nắm bắt nhất đối với người dùng CVS

Quan trọng hơn là một chiến lược di chuyển để tránh thời gian ngừng phát triển nếu di chuyển kho của họ không thành công

Các vấn đề liên quan