serwer subversion a dostęp do repozytorium sieciowego przez żółwia

Question

Obecnie w moim zespole jest 5 programistów i wszyscy uzyskujemy dostęp do repozytorium poprzez wspólny dysk na komputerze X, który znajduje się w naszej sieci. Ponieważ wszyscy mamy dostęp do komputera X i możemy zarządzać tym, kto ma i kto nie ma dostępu do komputera X, możemy zarządzać, kto może uzyskać dostęp do naszego repozytorium.

Moje pytanie brzmi: czy jeśli skonfiguruję serwer subversion, czy otrzymam jakąkolwiek funkcjonalność, której jeszcze nie mam? Repozytoria mają już wbudowaną kontrolę użytkownika/passwd.

1. Czy mogę śledzić, kto ma obecnie pobrany plik?
2. Czy mogę uzyskać blokadę dla więcej niż jednej osoby (tylko
   użytkownicy a i b mają zablokowany plik, żaden inny użytkownik nie może sprawdzić tego pliku )?
3. Czy mogę uzyskać jakiekolwiek zabezpieczenie?

Wygląda na to, że nie, ponieważ, znowu, już mam kontrolę użytkownika/grupy/passwd bez serwera.

Proszę dać mi znać. Podejmuję decyzję, czy jest jakaś korzyść z tworzenia serwera.

Dzięki JBU

Answer 1

Generalnie, nie "check out" plików w SVN. Oznacza to, że nie blokujesz ich podczas pracy nad nimi.

Zyskasz kilka rzeczy jednak (to tylko z wierzchu głowy):

• historia zmian (zarówno w jednym pliku, a dla repozytorium jako całość)
• Branch/Merge opcje
• możliwość oznacz wersje (często oficjalnymi wydaniami)
• zdolność do wycofywania zmian w pewnej rewizji (np jeśli poważny błąd został niedawno wprowadzony)
• i wiele, wiele więcej

Należy jednak zauważyć, że większość lub wszystkie z tych korzyści nie są unikalne dla działalności wywrotowej, ale można je uzyskać z większości nowoczesnych systemów kontroli wersji.

Answer 2

Tak, można zrobić kilka dodatkowych rzeczy:

• Dodatkowe mechanizmy uwierzytelniania (Basic Auth nad HTTP/S, ssh wspólne auth key)
• Korzystanie Apache + mod_dav_svn można skonfigurować drobniejsze szczegółową kontrolę dostępu na ścieżce według ścieżki

edycja: Nie jesteś pewien, czy korzystasz obecnie z subversion z udziału plików, czy tylko z uśpionego udziału plików. (SVN może również używać URI plików: ///).

Answer 3

Tak, zyskałbyś wiele: zmniejszasz ryzyko utraty wszystkich danych!

Zobacz dokumenty (i ostrzeżenia) na temat accessing a repository on a network share.

Answer 4

Po uzyskaniu dostępu do repozytorium poprzez adres URL file: ///, biblioteki subversion przyjmą, że repozytorium jest dostępne na dysku lokalnym i nie będzie próbowało (lub nawet będzie w stanie) zminimalizować sieciowe operacje we/wy. Uzyskiwanie dostępu do repozytorium za pośrednictwem adresu URL svn: /// jest zatem o wiele szybsze: o wiele szybsza dla niektórych operacji, w których wiele danych należy odczytać, aby określić ułamek, który należy wysłać do klienta, tak jak w przypadku svn switch dowództwo.

Nie ośmielę się mówić tego samego o http: // dostępie. Protokół http jest relatywnie rozmowny i nieefektywny w svn 1.5. Istnieje plans, aby poprawić to dla svn 1.7