Najlepszy sposób organizowania repozytorium Subversion wielu małych projektów

Question

Na początek, mam spojrzał na następnych stronach i nie bardzo mam odpowiedź: how-would-you-organize-a-subversion-repository-for-in-house-software-projects i how-do-you-organize-your-version-control-repository

Mam również wyglądał na rozdział 8 z Pragmatic Version Control using Subversion.

Wszyscy mają dobrą radę, ale ciężko mi jest powiązać to z moimi potrzebami.

Zasadniczo chcę zorganizować kod dla naszego serwera WWW. Mamy $ WEBROOT/htdocs i $ WEBROOT/cgi-bin. Pod naszym katalogiem htdocs mamy $ WEBROOT/htdocs/js i $ WEBROOT/htdocs/css dla skryptów java i arkuszy stylów.

Nasze "projekty" to nie są naprawdę projekty, ale małe fragmenty kodu - może skrypt Perla, plik skryptu java i arkusz stylów. Mamy około stu takich małych "projektów", które są prawie całkowicie niezależne od siebie, ale wszystkie żyją pod tym samym $ WEBROOT na tym samym serwerze internetowym.

Nasz kod nie jest jeszcze w subversion, ale chcę, żeby tak było - mam problem z jego efektywną organizacją. W razie potrzeby możemy mieć wiele repozytoriów SVN, ale jeśli każde repozytorium zawiera tylko 3-10 elementów, wydaje mi się to marnotrawstwem.

To, co myślałem, że może zadziałać, wygląda mniej więcej tak: Jeśli piszę skrypt, aby policzyć działające procesy na serwerze internetowym (na przykład). Załóżmy, że mam skrypt perl, plik js i plik css. Mógłbym wymienić webserver_processes "projekt" i sprawdzić go w repozytorium jako:

/svnrepo/webserver_processes/trunk 

Under bagażniku, mogę mieć:

htdocs/html/webserver_processes 
htdocs/js/webserver_processes 
htdocs/css/webserver_processes 
cgi-bin/webserver_processes 

nie mam żadnych statyczne dokumenty HTML w tym " projekt ", ale gdybym to zrobił, przejdą do katalogu" html ".

Korzyścią, którą widzę w tej strukturze, jest to, że mogę jednorazowo zrealizować jeden "projekt", nie wpływając na nic innego na serwerze sieciowym. Wadą (a może to nie jest żadna wada) jest wdrażanie. Musiałbym wdrożyć 1 projekt na raz z repozytorium. Nie widzę sposobu, w jaki można utworzyć kopię roboczą z moją strukturą $ WEBROOT/htdocs i $ WEBROOT/cgi-bin przy użyciu tej metody.

Inna opcja:

mógłbym stworzyć repozytorium SVN tak:

/svnrepo/webcode/trunk 

Pod bagażniku byłby cały kod na mój serwer WWW, w tych dwóch katalogach:

htdocs 
cgi-bin 

Wielką wadą byłoby to, że w przypadku niewielkiej zmiany kodu na 1 element, musiałbym sprawdzić każdy fragment kodu w moim środowisku internetowym ment. Zaletą (nieco) byłoby wykonanie "aktualizacji svn" na naszym serwerze internetowym w celu pobrania zmian wprowadzonych do repozytorium.

Może po prostu czynię to bardziej skomplikowanym, niż powinno być, ale czy ktoś ma jakąkolwiek radę na temat tego, jak skutecznie zorganizować mój kod w subwersji?

Wielkie dzięki z góry!

Brian

Answer 1

myślę robisz właściwą rozmowę poprzez utrzymywanie jednego repozytorium dla swoich wielu projektach, więc chciałbym zrobić tylko zmiany w procesie wdrażania:

Twój svn repo będzie wyglądać (pierwszej opcji.)

/svnrepo/project1/trunk 
/svnrepo/project1/trunk/htdocs 
/svnrepo/project1/trunk/css 
... 
/svnrepo/project1/branches/branch1 
/svnrepo/project1/tags/blah 
/svnrepo/project2/trunk 
/svnrepo/project3/trunk 

Jeśli chcesz wdrożyć, użyj skryptu, aby skopiować plik (i) do miejsca, w którym powinny zostać wdrożone.

W ten sposób zachowujesz sztuczną barierę (folder), aby uporządkować myśli między projektami, a nie tylko wielki bałagan plików.

edit: przypadkowo zapisane & dodatkowe katalogi dodane dla jasności

Answer 2

myślę najlepiej jest druga opcja: posiadanie cały kod pod jednym repo z htdocs i cgi-bin katalogów. To prawda, że ​​będziesz musiał sprawdzić cały kod, ale zrobisz to raz, a reszta zmian będzie znacznie mniejsza. Jeśli jest to serwer produkcyjny, to oczywiście musisz sprawdzić, czy cały twój kod jest gotowy do produkcji: utrzymuj tułów w zielonej tonie.

W przyszłości może równie dobrze pomóc w wyeliminowaniu podwójnej funkcjonalności.

Answer 3

Ponieważ nie jesteśmy zobowiązani do Subversion jeszcze rozważyć użycie Bazaar. Jest szczególnie dobrze przystosowany do kontroli wersji wielu małych projektów, ponieważ ma bardzo mały nakład pracy związanej z konfiguracją.

Answer 4

Najpierw użyj jednego repozytorium. Aby dowiedzieć się, jak dobrze można skalować pojedyncze repozytorium, spójrz na numer Apache svn repository. Wszystko jest jednym repozytorium.

Jeśli używasz pojedynczego łącza, które jest bezpośrednio wdrożone na serwerze internetowym, musisz upewnić się, że instalacja pozostaje gotowa. Oznacza to, że cały rozwój powinien najpierw nastąpić w oddziale, który zostanie ponownie włączony. Nie chcesz skończyć w sytuacji, w której jeden projekt jest w połowie ukończony, ale w systemie trunk, a inny projekt musi wykonać instalację błędu w bagażniku.

Nie martwiłbym się o wymagających osób, aby sprawdzić cały tułów, ale jeśli jest to prawdziwy problem, to może warto rozważyć hybrydowe podejście:

/svnrepo/trunk/project1/... 
/svnrepo/trunk/project2/... 
/svnrepo/deploy/htdocs 
/svnrepo/deploy/cgi-bin 

w tym przypadku, programiści musieliby zrobić svn copy z projektu w pniu do odpowiedniego miejsca w katalogu wdrażania. Możesz wtedy automatycznie wydać wszystko pod deploy.