Co do mojego przypadku… Uprośćmy sytuację i powiedzmy, że jest 2 DBA, którzy mają wydzielony serwer Linux z Apache i zainstalowanym SVN-em. Administrują sobie dwoma RDBMS Oracle na dwóch różnych serwerach Unix. Oczywiście konfiguracja baz danych jest inna (i przeważnie jest inna; zwykle inne są nazwy, ścieżki, ale przede wszystkim inne są parametry pamięciowe, które wymagają tuningu). Jeden z DBA idzie na urlop, a drugi pod jego nieobecność zmuszony był dokonać zmian w pliku konfiguracyjnym. Koleś wraca z wakacji, co prawda opalony, ale stopy odmrożone, bo był nad Bałtykiem ;-) i tu SVN wysłał do niego maila (?), że się coś zmieniło. Tak przynajmniej ja to widzę i jakoś to sobie tak wyobrażam…

1. Obsługa svn z punktu widzenia użytkownika (commit, checkout, add, rm, mv etc.)
2. Administracja serwerem svn (w moim przypadku apache + mod_dav + svn)
3. Znajomość środowiska UNIX-owego (cron, bash, etc.)

Trochę długi by był artykuł, choć nie jest powiedziane, że nie możliwy do zrobienia. Pogoogluj trochę. Jeśli masz jakieś pytania to możesz łapać mnie na priv. Łatwiej mi będzie pomóc Tobie, niż pisać całe howto – chyba, że więcej osób jest zainteresowanych.

Co do Twojego pytania o to jak trzymać konfigurację dla tych baz danych to też powstaje problem, czy mają one być wszystkie takie same na każdym z serwerów. Moje rozwiązanie dotyczyło N serwerów, przy czym każdy z nich pełnił inną funkcję (loadbalancer, firewall, db, app, cache, monitoring itp. itd.). Opisz dokładniej problem, to wtedy będę mógł Ci w stanie pomóc.

@hyc – a może jakis przykład w jakich to dużych firmach spotkaleś się z czymś takim?

Kolejna rzecz to, że chcemy mieć “świadome” commity, tylko przetestowanych rozwiązań. Wszelkie niecommitnięte rzeczy powinny zostać przejrzane – a nóż widelec coś się zmodyfikuje samo (update systemu, jakieś backdoory, źle napisane skrypty powłoki itp.)