2009-07-25 13 views
7

Po wybraniu Apache Subversion dla moich potrzeb kontroli wersji (i AnkhSVN/TortoiseSVN do moich pierwotnych klientów Subversion). Teraz próbuję wybrać serwer SVN, aby zapewnić zdalny dostęp do repozytoriów SVN. Mam spojrzał na kilka z nich:Wybór Subversion Server

mam zainstalowane każdy w VM je wypróbować, ale nie znalazłem wystarczająco odróżnić większość z nich na tyle, aby wybierz dowolny konkretny. Teraz mam kilka rzeczy, które muszę podjąć.

  1. protokół
  2. sprzedawca
  3. SSL


1. Czytałem, że protokół HTTP jest znacznie wolniej niż protokołu SVN. Podczas gdy moje projekty nie są zazwyczaj zbyt duże (tak naprawdę tylko początkowy import jest czasochłonną częścią), chcę uzyskać korzyści wydajności SVN, a także uniknąć zalania logów HTTP wpisami SVN (które nie udało się oddzielić w pliku sepate LOG).

Podobają mi się jednak interfejsy internetowe, które wykorzystują moduł Apache lub VisualSVN. Nie muszę dostarczać moich rzeczy innym (lub nawet sobie z dala od mojego systemu), więc nie jest to krytyczne, ale z pewnością pozwala na rozbudowę.


2. Po wybraniu protokołu (zakładając, że I ma do wyboru); Potrzebuję pomocy w wyborze sprzedawcy. Pierwotnie użyłem modułu Apache z dystrybucji Tigris. Od tego czasu usunąłem (no cóż, po prostu go wyłączono) i obecnie używam VisualSVN (który jest HTTP i tym samym powolny). Widziałem ludzi popierających Sharpa i Silka, ale wydają się być mniejsi, indie distros.
Z drugiej strony wydaje się, że Collabnet jest bardziej rozbudowany, niż potrzebuję. Zasadniczo, jeśli nie mogę być przekonany do jednego z nich, głównie staram się wybierać pomiędzy oficjalnym Tigris i VisualSVN.


3. Próbowałem także mieszać się z SSL bez większego sukcesu (nie stać mnie na prawdziwy CA, więc używam samopodpisanego certyfikatu w VisualSVN). Byłbym szczęśliwy, gdyby używałem SVN + SSH/HTTPS, ale jeśli używam go w swoim własnym systemie, to nie jest to konieczne, i jeśli używam go na zewnątrz, to mój samopodpisany certyfikat nie pomoże.


Przypuszczam, że mógłbym nawet użyć lokalnego repozytorium; Myślę, że byłoby to najszybsze. Jednak wolałbym bardziej formalne rozwiązanie w przypadku, gdybym się rozwinął. (I uważane tylko za pomocą klienta TortiseSVN do pracy serwera lokalnie.)


Tak w skrócie, potrzebuję porady na który serwer (s?) Użyć.Byłoby świetnie, gdyby udało mi się uzyskać VisualSVN, aby zapewnić interfejs HTTP do korzystania z sieci, ale również służyć do protokołu SVN do użytku w klientach, najlepiej z opcją SSL na każdym z nich. Czy to jest możliwe? Czy to byłoby zbyt dużo pracy (naprawdę chcę wrócić do pracy nad moimi projektami, a nie całego tego meta-pracy).



Wielkie dzięki.

Edit

pomyślałem, że powinienem dać trochę informacji na temat mojej sytuacji w celu wyjaśnienia sprawy.

  • (obecnie) jednolity system, (starsza P4, Okna, 1GB SDRAM)
  • (Obecnie) Single developer (ME)
  • (Obecnie) Stosunkowo małe projekty (< 2MB)
  • Niezliczone projekty (> 100 pojedynczych aplikacji, gier, bibliotek, witryn internetowych itp.)
  • Wymagane zewnętrzne (konkretnie moja własna biblioteka oraz nagłówek innej firmy, Zwiększ, itp.)
  • ? Hmm, co jeszcze ...
+3

nadal jestem noobish, ale wydaje mi się, że jest to pytanie, które byłyby właściwie poprosił o ServerFault: http://serverfault.com –

+0

Mam kilka projektów 100 MB, tylko za pomocą dostępu HTTP. Wydajność wcale nie jest problemem. Nie martwiłbym się ani nie przejmowałbym svn: //, dopóki wydajność nie jest dla ciebie problemem. – nos

Odpowiedz

5

Edit: Po przeczytaniu innych odpowiedzi tutaj, jest jedna rzecz, pomyślałem, że powinienem wspomnieć. Jeśli spróbujesz jednego serwera, repozytorium, o które go poprosisz, nie będzie się różnić od repozytoriów, o które pytasz serwer innego typu.

Innymi słowy, jeśli zdecydujesz się teraz wypróbować jeden serwer, możesz później przełączyć się na inny typ serwera, bez utraty repozytoriów. Oczywiście kopie robocze i wszelkie odniesienia zewnętrzne, które wykonałeś w swoich projektach, będą musiały ulec zmianie, ale możesz przechowywać swoje repozytorium z historią i wszystkimi innymi.


Zainstalowałem VisualSVN Server po ogłoszeniu i byłem z niej całkiem zadowolony, przez jakiś czas.

Jednak problemy z prędkością spowodowały, że przełączyłem się na główny serwer svnserve dostarczany jako część pakietu linii poleceń Subversion.

Głównym problemem jest to, że pracuję z .NET i zdecydowałem się dodać kilka zewnętrznych referencji Subversion do moich projektów.

Przede wszystkim każdy projekt, który wykonuję w bibliotece zajęć jest podpisany przez mój klucz. Po drugie zewnętrzne biblioteki zewnętrzne, takie jak SQLite i NUnit zostały dodane jako odniesienia zewnętrzne.

Każdy projekt miał swoje własne odniesienia zewnętrzne. Zrobiłem to, aby móc utworzyć nowy projekt aplikacji, a następnie utworzyć nowe odwołania zewnętrzne do części mojej biblioteki klas, której potrzebowałem i aby te odniesienia były kompletne. Jeśli moje rozwiązanie klasy bibliotek w .NET ma jedno zewnętrzne odwołanie do pliku klucza podpisu, a ten plik nie był dostępny jako część pojedynczego projektu, ale znajdował się na dysku poza wszystkimi projektami, ale lokalnie w moim rozwiązaniu, to nie działa.

Moje rozwiązanie z biblioteki klas zawiera około 15-20 projektów, z których każdy ma przynajmniej jedno zewnętrzne odwołanie do klucza podpisu, wszystkie moje projekty danych mają zewnętrzne odwołania do biblioteki SQLite, a biblioteka testów jednostkowych ma 4-5 odniesienia zewnętrzne.

Wynik netto był taki, że pojedyncza aktualizacja na poziomie rozwiązania, nawet jeśli miałem już wszystkie najnowsze pliki, katalogi, wszystko, zajęło około 2 minut. Każda zewnętrzna wzmianka trwała od 10 do 20 sekund, aby zweryfikować, czy potrzebowałem wersji, której potrzebowałem.

Po przełączeniu na svnserve te 2 minuty zostały zredukowane do około 3 sekund. To jest lokalny ruch drogowy, więc oczywiście będzie to różnić się w Internecie. Problem w tym, że te 2 minuty były również ruchem lokalnym.

Tak, a ja absolutnie zachwyceni interfejs VisualSVN Server dostarczył mi, w tym zdolność do łatwo skonfigurować prawa dostępu i użytkowników, prędkość, że moduł serwera Apache dostarczyła mi było absolutnie straszne w porównaniu z tym, co svnserve i rodzimy protokół Subversion.

Zauważ, że od tego czasu zainstalowałem osobny serwer Apache, przebrnąłem przez wiele plików konfiguracyjnych i skonfigurowałem Subversion z Apache innym niż za pośrednictwem serwera VisualSVN, tylko po to, aby upewnić się, że nie był to tylko VisualSVN, a ja potwierdziła, że ​​obserwowana prędkość nie była pracą zespołu VisualSVN. Wygląda na to, że protokół HTTP lub moduły Apache nie są tak szybkie.

Moja rada to pójść z głównym serwerem svnserve, jeśli to możliwe. Może to zająć trochę pracy, aby poznać pliki konfiguracyjne do autoryzacji i podobnych, ale sam czynnik podrażnienia (tj. Brak podrażnienia nad prędkością) prawdopodobnie przeważy nad tym.

+0

Podoba mi się informacja o standardowych repozytoriach, a więc przenośnych. To mówi mi, że mogę po prostu trzymać się tego, co mam obecnie, i zmienić jako/w razie potrzeby. – Synetech

+1

Poprawiono protokół HTTP w Subversion 1.7: http://subversion.apache.org/docs/release-notes/1.7.html#httpv2 –

0

Używam CollabNet w domu i pracy. Wszystko było w porządku - żadnych reklamacji z wydajnością.

2

Ponowna prędkość dostępu: Widziałem serwer SVN Apache https: wymagający aktualizacji sprzętu. Wydaje mi się, że pamiętam, że to głównie brak pamięci spowolnił liczne procesy Apache, które rywalizowały o zasoby maszyny. Ale to było 20 programistów współpracujących nad projektem z wyrejestrowanym drzewkiem 20 GB (wiele plików binarnych, które często się zmieniały). Aktualizacja na umiarkowanie wyposażonym serwerze rozwiązała problem.

Również w tym projekcie musiałem się nauczyć, że SVN na ext3 FS pod Linuksem było o rząd wielkości szybsze niż na NTFS w Windows. Zaznaczyć, że: Linux na maszynie wirtualnej działającej w systemie Windows potrzebował jednej dziesiątej czasu, aby aktualizacja konkurowała z polem Windows, w którym uruchomiona została maszyna wirtualna. (Zawsze chcieliśmy wypróbować ten sterownik OS ext3 dla Windows i sprawdzić, czy nie sprawiłoby to, że SVN byłby szybszy w systemie Windows niż jego natywny FS. Jednak opuściłem projekt, zanim zdążyliśmy go obejść.)

W każdym razie nie jest tak, jak decydujesz, jest rzucony w kamień na wieczność. Możesz wypróbować jedną rzecz, przetestować ją dokładnie w prawdziwym projekcie i przełączyć się na inny serwer i protokół później. (Jest nawet polecenia SVN aby przełączyć URL z wyrejestrowany drzewa ten można wykorzystać do przełączania protokołu bez konieczności sprawdzić wszystko od nowa.).

Oto co uważam zdecydować o protokole: Jeśli masz działającą infrastrukturę AD lub LDAP, którą chciałbyś wykorzystać do logowania do SVN, wypróbuj jedną z opcji protokołu http/https:. Jeśli nie masz tego i nie będziesz go potrzebować, a Ty dobrze się logujesz, korzystając z własnych środków SVN, dlaczego nie skorzystać z prędkości dostarczonej przez protokół svn:?

Nigdy nie widziałem repozytorium SVN, do którego ludzie korzystali z dostępem do WebDAV. IME zawsze chcą mieć historię podczas uzyskiwania dostępu do sieci (WebDAV tego nie zapewnia, AFAIK), więc użyli jednego z interfejsów internetowych dla SVN.Nigdy nie sprawdzałem, ale zakładam, że takie rzeczy jak ViewVC i tym podobne nie obchodzą protokół, którego używają do uzyskania dostępu do repozytorium.

Jeśli chodzi o dystrybucję, której chcesz użyć - myślę, że zależy to głównie od osobistych preferencji, ponieważ kod pod spodem jest taki sam. Wolę pliki do pobrania, których nie muszę rejestrować, oraz dystrybucje, które wyraźnie mają na celu platformę, na której chcę je zainstalować. Ale to prawdopodobnie tylko ja.

Jest jednak jeden trudny fakt, który warto rozważyć, jeśli repozytorium jest dostępne z Internetu: Kiedy projekt SVN wykonał nową wersję dot, jak dawno, w przeszłości, różne dystrybucje nadrabiają zaległości . Ponieważ mogą to być poprawki zabezpieczeń, możesz preferować te, które zazwyczaj zapewniają poprawki szybciej.

1

Dostarczamy nasze repozytorium SVN za pomocą HTTP dostarczonego przez Apache działającego pod CentOS 5.3 z wnętrza wirtualnej maszyny XEN.

Obserwowałbym, że robi zatwierdzenie lub kasie dużego pliku, przesyła ten plik z prędkością bliską prędkości sieci. Podczas sprawdzania lub zatwierdzania dużej liczby małych plików obciążenie związane z żądaniami HTTP jest znacznie bardziej zauważalne.

W porównaniu do skali czasowej w kompilacji kodu, SubVersion nie jest postrzegany jako wąskie gardło wewnątrz firmy.

(To jest moje doświadczenie z zespołem 10 deweloperów)