Jedno repozytorium SVN czy wiele?

Jeśli masz wiele niepowiązanych projektów, czy warto umieścić je w tym samym repozytorium?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

czy może stworzyłbyś nowe repozytoria dla każdego?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

Jakie są zalety i wady każdego z nich? Jedyne, o czym mogę obecnie pomyśleć, to to, że otrzymujesz mieszane numery wersji (i co z tego?) I nie możesz ich używać, svn:externalschyba że repozytorium jest faktycznie zewnętrzne. (Myślę?)

Pytam, ponieważ rozważam konsolidację moich wielu repozytoriów w jedno, ponieważ mój host SVN zaczął naliczać opłaty za repozytorium.

Pojedynczy lub wielokrotny problem sprowadza się do osobistych lub organizacyjnych preferencji.

Zarządzanie wieloma lub pojedynczym sprowadza się głównie do kontroli dostępu i konserwacji.

Kontrola dostępu do pojedynczego repozytorium może być zawarta w jednym pliku; Wiele repozytoriów może wymagać wielu plików. Konserwacja ma podobne problemy - jedna duża kopia zapasowa lub wiele małych kopii zapasowych.

Zarządzam własnym. Jest jedno repozytorium, wiele projektów, każdy z własnymi tagami, linią główną i gałęziami. Jeśli jeden jest zbyt duży lub potrzebuję fizycznie odizolować kod klienta dla jego wygody, mogę szybko i łatwo utworzyć nowe repozytorium.

Niedawno konsultowałem się ze stosunkowo dużą firmą w sprawie migracji wielu systemów kontroli kodu źródłowego do Subversion. Mają około 50 projektów, od bardzo małych po aplikacje korporacyjne i korporacyjną stronę internetową. Ich plan? Zacznij od jednego repozytorium, w razie potrzeby przeprowadź migrację do wielu. Migracja jest prawie zakończona i nadal znajdują się w jednym repozytorium, nie zgłoszono żadnych skarg ani problemów, ponieważ jest to pojedyncze repozytorium.

To nie jest kwestia binarna, czarno-biała.

Rób to, co działa dla Ciebie - gdybym był na twoim stanowisku, łączyłbym projekty w jedno repozytorium tak szybko, jak potrafiłbym wpisywać polecenia, ponieważ koszt byłby głównym czynnikiem rozważanym w mojej (bardzo, bardzo małej) firmie.

JFTR:

numery wersji w Subversion naprawdę nie mają znaczenia poza repozytorium. Jeśli potrzebujesz znaczących nazw dla rewizji, utwórz TAG

Komunikaty o zatwierdzeniach można łatwo filtrować według ścieżki w repozytorium, więc czytanie tylko tych związanych z danym projektem jest trywialnym ćwiczeniem.

Edycja: Zobacz odpowiedź Blade , aby uzyskać szczegółowe informacje na temat korzystania z pojedynczej konfiguracji autoryzacji / uwierzytelniania dla SVN.

Dla twojego konkretnego przypadku jedno (1) repozytorium jest idealne. Zaoszczędzisz dużo pieniędzy. Zawsze zachęcam ludzi do korzystania z jednego repozytorium. Ponieważ jest podobny do pojedynczego systemu plików: jest łatwiejszy

• Będziesz mieć jedno miejsce, w którym szukasz kodu
• Będziesz mieć jedną autoryzację
• Będziesz mieć jeden numer zatwierdzenia (kiedykolwiek próbowałeś zbudować projekt, który jest rozłożony na 3 repozytoria?)
• Możesz lepiej ponownie używać wspólnych bibliotek i śledzić swoje postępy w tych bibliotekach (svn: zewnętrzne to PITA i nie rozwiążą wszystkich problemów)
• Projekty zaplanowane jako całkowicie różne elementy mogą rosnąć razem i współdzielić funkcje i interfejsy. Będzie to bardzo trudne do osiągnięcia w przypadku wielu repozytoriów.

Istnieje jeden punkt dotyczący wielu repozytoriów: administrowanie ogromnymi repozytoriami jest niewygodne. Zrzucanie / ładowanie ogromnych repozytoriów zajmuje dużo czasu. Ale ponieważ nie zajmujesz się żadną administracją, myślę, że to nie będzie Twoje zmartwienie;)

SVN bardzo dobrze skaluje się z większymi repozytoriami, nie ma spowolnienia nawet w przypadku ogromnych (> 100 GB) repozytoriów.

Dzięki temu będziesz mieć mniej kłopotów z pojedynczym repozytorium. Ale naprawdę powinieneś pomyśleć o układzie repozytorium!

Użyłbym wielu repozytoriów. Oprócz problemu z dostępem użytkownika ułatwia również tworzenie kopii zapasowych i przywracanie. A jeśli znajdziesz się w sytuacji, w której ktoś chce Ci zapłacić za Twój kod (i jego historię), łatwiej jest dać mu tylko zrzut repozytorium.

Sugerowałbym, że konsolidacja repozytoriów tylko ze względu na politykę opłat Twojego dostawcy hostingu nie jest dobrym powodem.

Korzystamy z jednego repozytorium. Moim jedynym zmartwieniem była skala, ale po obejrzeniu repozytorium ASF (700 tys. Wersji i zliczenia) byłem przekonany, że wydajność nie będzie problemem.

Wszystkie nasze projekty to różne, powiązane ze sobą moduły, które tworzą zestaw zależności dla dowolnej aplikacji. Z tego powodu jedno repozytorium jest idealne. Możesz potrzebować oddzielnego pnia / gałęzi / tagów dla każdego projektu, ale nadal możesz atomowo zatwierdzić zmianę w całej bazie kodu w ramach jednej wersji. To jest świetne do refaktoryzacji.

Pamiętaj, że podejmując decyzję, wiele repozytoriów SVN może współużytkować ten sam plik konfiguracyjny.

Przykład (wzięty z linku powyżej):

W skorupkach:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

Plik: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

Plik: / var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

Utworzyłbym osobne repozytoria ... Dlaczego? Numery wersji i komunikaty o zatwierdzeniach po prostu nie będą miały sensu, jeśli masz wiele niepowiązanych projektów w tylko jednym repozytorium, na pewno będzie to duży bałagan w krótkim okresie ...

Jesteśmy małą firmą programistyczną i używamy jednego repozytorium do całego naszego rozwoju. Drzewo wygląda tak:

/client/<clientname>/<project>/<trunk, branches, tags>

Pomysł był taki, że będziemy mieć klienta i pracę wewnętrzną w tym samym repozytorium, ale ostatecznie nasza firma była „klientem” siebie.

To zadziałało dla nas naprawdę dobrze i używamy Traca do połączenia się z nim. Numery wersji dotyczą całego repozytorium i nie są specyficzne dla jednego projektu, ale to nas nie zmienia.

Osobiście stworzyłbym nowe repozytoria dla każdego. Dzięki temu proces sprawdzania jest znacznie prostszy i ogólnie administracja jest łatwiejsza, przynajmniej w odniesieniu do dostępu użytkowników i kopii zapasowych. Ponadto unika problemu z globalnym numerem wersji, więc numer wersji ma znaczenie we wszystkich projektach.

Naprawdę jednak powinieneś po prostu użyć git;)

jedną dodatkową rzeczą do rozważenia jest fakt, że korzystanie z wielu repozytoriów powoduje utratę możliwości ujednoliconego rejestrowania (polecenie svn log), samo to będzie dobrym powodem do wybrania jednego repozytorium.

Używam TortuiseSvn i stwierdziłem, że opcja „Pokaż dziennik” jest obowiązkowym narzędziem. Chociaż twoje projekty są niepowiązane, jestem pewien, że okaże się, że posiadanie scentralizowanych, globalnych informacji o różnych projektach (ścieżki, identyfikatory błędów, komunikaty itd.) jest zawsze przydatne.

Jeśli planujesz lub używasz narzędzia takiego jak trac, które integruje się z SVN, bardziej sensowne jest użycie jednego repozytorium na projekt.

Podobnie jak w przypadku sugestii Blade'a dotyczącej udostępniania plików, tutaj jest nieco łatwiejsze, ale mniej elastyczne rozwiązanie. Skonfigurowałem nasze tak:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

W "bin" trzymam skrypt o nazwie svn-create.sh, który wykona całą konfigurację tworzenia pustego repozytorium. Mam tam również skrypt kopii zapasowej.

W "repository_files" trzymam wspólne katalogi "conf" i "hooks", do których wszystkie repozytoria mają dowiązania symboliczne. Wtedy jest tylko jeden zestaw plików. Eliminuje to jednak możliwość uzyskania szczegółowego dostępu do projektu bez przerywania łączy. To nie był problem, kiedy to ustawiłem.

Na koniec utrzymuję główny katalog / var / svn pod kontrolą źródła, ignorując wszystko w svnroot. W ten sposób pliki repozytorium i skrypty są również pod kontrolą źródła.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Podobnie jak w mlambie używających pojedynczego repozytorium, ale poszło nieco dalej ze strukturą folderów, aby łatwo powiększyć do określonego typu projektów - projekty oparte na web html vs. cs (C #) vs. sql (tworzenie / wykonywanie skryptów SQL) vs. xyz ( Języki specyficzne dla domeny, takie jak afl (AmiBroker Formula Language) lub ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Uwaga, linia główna jest w gałęziach, ponieważ traktuję ją jako gałąź domyślną. Czasami jedynym problemem jest, gdy chcesz szybko utworzyć inny projekt, musisz zbudować strukturę ProjectName / branches | tags. Używam ustawień aplikacji po prostu jako miejsca do przechowywania określonych plików ustawień aplikacji w repozytorium, które można łatwo udostępniać innym (i zastępuję ClientName na VendorName i ProjectName na AppName w tej strukturze folderów; a gałęzie | tagi mogą być przydatne do oznaczania ustawień w różnych głównych wersje produktów dostawców).

Witam wszystkich komentarzy na temat mojej struktury - ostatnio zmieniłem to na taką i do tej pory bardzo się cieszę, ale czasami uważam, że utrzymanie struktur gałęzi | tagów na projekt jest uciążliwe - szczególnie jeśli projekt jest po prostu konfiguracją projektu po prostu do testu jednostkowego innego projektu.

Moja sugestia jest jedna. Jeśli nie masz różnych użytkowników uzyskujących dostęp do każdego z nich, powiedziałbym, że użyj wielu.

Ale znowu, nawet to nie jest dobry powód, aby używać wielu.