2009-07-25 18 views
7

Sau khi chọn Apache Subversion cho các nhu cầu kiểm soát phiên bản của tôi (và AnkhSVN/TortoiseSVN cho khách hàng Subversion chính của tôi). Bây giờ tôi đang cố gắng chọn máy chủ SVN để cung cấp truy cập từ xa vào kho SVN. Tôi đã xem xét một vài trong số họ:Chọn một Subversion server

Tôi đã cài đặt mỗi trong một máy ảo để thử chúng ra nhưng đã không tìm thấy đủ để phân biệt hầu hết trong số họ đủ để chọn bất kỳ cụ thể. Bây giờ tôi có một vài điều tôi cần phải quyết định.

  1. giao thức
  2. nhà cung cấp
  3. SSL


1. Tôi đã đọc HTTP đó là nhiều chậm so với giao thức SVN. Mặc dù dự án của tôi không quá lớn (thực sự chỉ nhập ban đầu là phần tốn thời gian), tôi muốn nhận được lợi ích hiệu suất của SVN, cũng như tránh các bản ghi HTTP bị ngập với các mục SVN (mà tôi vẫn chưa thể tách biệt thành tệp LOG seprate).

Tuy nhiên, tôi thích giao diện web sử dụng mô đun Apache hoặc VisualSVN. Tôi không thực sự cần phải cung cấp nội dung của mình cho người khác (hoặc thậm chí tôi không phải là hệ thống của tôi), vì vậy nó không phải là quan trọng, nhưng nó chắc chắn cho phép khả năng mở rộng.


2. Sau khi chọn giao thức (giả sử tôi để chọn); Tôi cần trợ giúp quyết định những gì nhà cung cấp để sử dụng. Ban đầu tôi đã sử dụng mô-đun Apache từ bản phân phối của Tigris. Tôi có kể từ khi loại bỏ đó (tốt, chỉ cần vô hiệu hóa nó), và hiện đang sử dụng VisualSVN (đó là HTTP và do đó chậm). Tôi đã chứng kiến ​​mọi người ủng hộ Sharp và Silk nhưng dường như họ lại nhỏ hơn, sự phân tán độc lập.
Mặt khác, Collabnet có vẻ phức tạp hơn tôi cần. Về cơ bản, trừ khi tôi có thể thuyết phục được một trong số đó, tôi chủ yếu chỉ cố gắng chọn giữa Tigris và VisualSVN chính thức.


3. Tôi cũng đã cố gắng lộn xộn với SSL mà không thành công nhiều (tôi không đủ tiền để mua CA thực, vì vậy tôi đang sử dụng chứng chỉ tự ký trong VisualSVN). Tôi rất vui khi sử dụng SVN + SSH/HTTPS, nhưng nếu tôi đang sử dụng nó trên hệ thống của riêng mình thì không cần thiết và nếu tôi sử dụng nó bên ngoài thì chứng chỉ tự ký của tôi sẽ không hữu ích.


Tôi cho rằng tôi thậm chí có thể sử dụng kho lưu trữ cục bộ; Tôi nghĩ rằng nó sẽ là nhanh nhất. Tuy nhiên tôi thích một giải pháp chính thức hơn trong trường hợp tôi mở rộng. (Tôi coi chỉ sử dụng cho khách hàng TortiseSVN để làm công việc của máy chủ tại địa phương.)


Vì vậy, trong Tóm lại, tôi cần một số lời khuyên mà máy chủ (s?) Để sử dụng.Điều gì sẽ là tuyệt vời nếu tôi có thể có được VisualSVN để cung cấp một giao diện HTTP để sử dụng web, nhưng cũng phục vụ trên một giao thức SVN để sử dụng trong các khách hàng, tốt nhất là với các tùy chọn SSL trên mỗi. Điều đó có thể không? Nó sẽ là quá nhiều công việc (tôi thực sự muốn trở lại làm việc trên các dự án của tôi chứ không phải tất cả các siêu-công việc này).



Cảm ơn rất nhiều.

Sửa

tôi nghĩ tôi nên cho một ít thông tin về hoàn cảnh của tôi để làm rõ điều này.

  • (Hiện nay) Độc hệ thống, (P4 cũ, Windows, 1GB SDRAM)
  • (Hiện nay) Độc thân nhà phát triển (tôi)
  • dự án
  • (Hiện nay) tương đối nhỏ (< 2MB)
  • dự án Vô số (> 100 ứng dụng, trò chơi, thư viện, trang web cá nhân, v.v.)
  • Yêu cầu bên ngoài (cụ thể thư viện của riêng tôi cũng như tiêu đề của bên thứ ba, Tăng cường, v.v.)
  • ? hmm, còn gì khác…
+3

Tôi vẫn noobish, nhưng tôi đoán là đây là một câu hỏi mà sẽ được yêu cầu đúng trên Serverfault: http://serverfault.com –

+0

Tôi đã có vài dự án 100Mb chỉ sử dụng truy cập HTTP. Hiệu suất không phải là một vấn đề. Tôi sẽ không lo lắng hoặc bận tâm với svn: // cho đến khi hiệu suất là một vấn đề thực sự cho bạn. – nos

Trả lời

5

Chỉnh sửa: Sau khi đọc các câu trả lời khác ở đây, có một điều tôi nghĩ tôi nên đề cập đến. Nếu bạn thử một máy chủ, các kho lưu trữ mà bạn yêu cầu nó sẽ không khác với các kho lưu trữ mà bạn yêu cầu một loại máy chủ khác để phục vụ.

Nói cách khác, nếu bạn quyết định thử một máy chủ ngay bây giờ, bạn có thể chuyển sang một loại máy chủ khác sau này mà không làm mất kho lưu trữ của bạn. Tất nhiên, các bản sao làm việc, và bất kỳ tài liệu tham khảo tuyệt đối bên ngoài mà bạn đã thực hiện trong dự án của bạn, sẽ phải thay đổi, nhưng bạn có thể giữ kho của bạn với lịch sử và tất cả.


Tôi đã cài đặt VisualSVN Server khi được thông báo và khá hài lòng với nó trong một thời gian.

Tuy nhiên, các vấn đề về tốc độ khiến tôi chuyển sang máy chủ svnserve chính được vận chuyển như là một phần của gói dòng lệnh Subversion.

Vấn đề chính là tôi đang làm việc với .NET và tôi đã chọn thêm một số tham chiếu Subversion bên ngoài vào dự án của mình.

Trước hết, mọi dự án tôi thực hiện trong thư viện lớp học của mình đều được ký bởi khóa của tôi. Thứ hai, các thư viện bên thứ ba bên ngoài, như SQLiteNUnit đã được thêm làm tham chiếu bên ngoài.

Mọi dự án đều có tham chiếu bên ngoài của riêng họ. Tôi đã làm điều này để có thể thực hiện một dự án ứng dụng mới, và sau đó tạo các tham chiếu mới bên ngoài tới các phần của thư viện lớp học của tôi mà tôi cần, và để các tham chiếu đó hoàn thành. Nếu giải pháp thư viện lớp của tôi trong .NET có một tham chiếu ngoài cho tệp khóa ký và tệp đó không có sẵn như là một phần của bất kỳ dự án nào, nhưng nằm trên đĩa bên ngoài tất cả các dự án, nhưng cục bộ cho giải pháp của tôi không làm việc.

Vì vậy, giải pháp thư viện lớp của tôi chứa khoảng 15-20 dự án, mỗi dự án có ít nhất một tham chiếu bên ngoài cho khóa ký, tất cả dự án dữ liệu của tôi có tham chiếu bên ngoài vào thư viện SQLite và thư viện kiểm tra đơn vị có 4-5 tham chiếu bên ngoài.

Kết quả thực là một bản cập nhật duy nhất ở cấp độ giải pháp, ngay cả khi tôi đã có tất cả các tệp, thư mục, mọi thứ mới nhất, mất khoảng 2 phút để hoàn thành. Mỗi tài liệu tham khảo bên ngoài chỉ mất khoảng 10 đến 20 giây để hoàn thành, chỉ để xác minh rằng tôi đã có bản sửa đổi tôi cần.

Khi tôi chuyển sang svnserve, 2 phút đó đã giảm xuống còn khoảng 3 giây. Đây là lưu lượng truy cập địa phương tâm trí bạn, do đó, tất nhiên điều này sẽ khác nhau trên internet. Vấn đề là, 2 phút đó cũng là lưu lượng truy cập cục bộ. Vì vậy, trong khi tôi hoàn toàn yêu giao diện VisualSVN Server cung cấp cho tôi, bao gồm khả năng dễ dàng thiết lập quyền truy cập và người dùng, tốc độ mà mô-đun máy chủ Apache cung cấp cho tôi là hoàn toàn khủng khiếp so với những gì svnserve và giao thức Subversion nguyên gốc. Lưu ý rằng sau đó tôi đã cài đặt một máy chủ Apache riêng biệt, lội qua rất nhiều tệp cấu hình và thiết lập Subversion với Apache ngoài máy chủ VisualSVN, chỉ để đảm bảo rằng nó không chỉ là VisualSVN, và tôi đã xác nhận rằng tốc độ tôi quan sát không phải là công việc của nhóm VisualSVN. Có vẻ như giao thức HTTP hoặc các mô đun Apache không nhanh như vậy.

Lời khuyên của tôi là đi với máy chủ svnserve chính, nếu có thể. Nó có thể mất một số công việc để có được biết các tập tin cấu hình cho phép và thích, nhưng các yếu tố kích thích một mình (tức là không có kích thích trên tốc độ ở tất cả) sẽ nhiều hơn khả năng lớn hơn điều đó.

+0

Tôi thích thông tin về các kho lưu trữ là tiêu chuẩn và do đó di động. Điều đó nói với tôi rằng tôi chỉ có thể gắn bó với những gì tôi có mà hiện đang làm việc, và thay đổi như/nếu cần thiết. – Synetech

+1

Giao thức HTTP đã được cải thiện trong Subversion 1.7: http://subversion.apache.org/docs/release-notes/1.7.html#httpv2 –

0

Tôi đang sử dụng CollabNet ở nhà và tại cơ quan. Nó ổn - không có khiếu nại về hiệu suất.

2

Tốc độ truy cập lại: Tôi đã thấy máy chủ Apache https: SVN cần cập nhật phần cứng. Tôi dường như nhớ nó chủ yếu là thiếu bộ nhớ mà làm chậm quá trình Apache rất nhiều mà cạnh tranh cho các nguồn tài nguyên của máy. Nhưng đó là 20 nhà phát triển cộng tác trong một dự án với cây được kiểm tra là 20GB (rất nhiều tệp nhị phân trong đó, thường thay đổi). Và bản cập nhật cho một máy chủ được trang bị vừa phải đã giải quyết được sự cố.

Ngoài ra, trong chính dự án đó, tôi đã phải biết rằng SVN trên một FS3 ext3 trong Linux có mức độ nhanh hơn so với NTFS trên Windows. Đánh dấu rằng: Linux trong một máy ảo chạy trên Windows mất một phần mười thời gian cho một bản cập nhật cạnh tranh với hộp Windows VM chạy trên. (Chúng tôi luôn có ý định thử trình điều khiển OS ext3 đó cho Windows và xem liệu điều này có làm cho SVN nhanh hơn trên Windows so với bản gốc FS của nó hay không. Tuy nhiên, tôi đã rời khỏi dự án trước khi chúng tôi thử nghiệm.)

Dù sao, nó không giống như những gì bạn quyết định được đúc vào đá vĩnh cửu. Bạn có thể thử một thứ, kiểm tra kỹ lưỡng nó trong một dự án thực, và chuyển sang một máy chủ và giao thức khác sau này. (Thậm chí còn có lệnh SVN để chuyển đổi URL của cây đã kiểm tra. Điều này bạn có thể sử dụng để chuyển đổi giao thức mà không cần phải kiểm tra lại mọi thứ.)

Đây là những gì tôi sẽ xem xét để quyết định về giao thức: bạn có cơ sở hạ tầng AD hoặc LDAP đang hoạt động mà bạn muốn tận dụng để đăng nhập vào SVN, hãy thử một trong các tùy chọn giao thức http/https:. Nếu bạn không có điều này, và bạn sẽ không cần nó, và bạn đang làm tốt đăng nhập bằng phương tiện riêng của SVN, tại sao không sử dụng tốc độ được cung cấp bởi giao thức svn:?

Tôi chưa bao giờ thấy một repo SVN mà mọi người sử dụng truy cập WebDAV. IME họ luôn muốn có lịch sử khi truy cập vào mỗi trang web (WebDAV không cung cấp cái này, AFAIK), vì vậy họ đã sử dụng một trong các giao diện web cho SVN.Tôi đã không bao giờ kiểm tra, nhưng tôi chỉ giả định rằng các công cụ như ViewVC và như thế không quan tâm giao thức mà họ sử dụng để truy cập vào repo.

Khi phân phối bạn muốn sử dụng - tôi nghĩ chủ yếu là tùy theo sở thích cá nhân, vì mã bên dưới vẫn giống nhau. Tôi thích tải xuống Tôi không phải đăng ký và phân phối rõ ràng nhắm vào nền tảng mà tôi muốn cài đặt chúng trên đó. Nhưng đó có lẽ chỉ là tôi. Tuy nhiên, có một thực tế khó khăn bạn có thể muốn xem xét nếu kho lưu trữ của bạn có thể truy cập từ Internet: Khi dự án SVN thực hiện một phát hành dấu chấm mới, trong bao lâu, trong quá khứ, có các bản phân phối khác nhau để bắt kịp . Vì đây có thể là các bản sửa lỗi bảo mật, bạn có thể thích các bản sửa lỗi thường, cung cấp các bản sửa lỗi nhanh hơn.

1

Chúng tôi cung cấp kho SVN của chúng tôi bằng cách sử dụng HTTP do Apache cung cấp chạy dưới CentOS 5.3 từ bên trong máy ảo XEN.

Tôi muốn quan sát thực hiện cam kết hoặc thanh toán trên một tệp lớn, chuyển tệp đó ở gần tốc độ mạng. Trong khi kiểm tra hoặc cam kết một số lượng lớn các tệp nhỏ, chi phí của các yêu cầu HTTP là đáng chú ý hơn nhiều.

So với thời gian trong quá trình biên dịch mã, SubVersion không được xem là nút cổ chai trong công ty.

(Đây là kinh nghiệm của tôi với một đội ngũ 10 nhà phát triển)

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