Pewnie większość z was pisząc klasy napotyka na pewien problem.

Część z tych klas ciągle się powtarza i z czasem budujecie taki swój zestaw wielokrotnego użytku. Problem jednak jak go utrzymać, stosować w wielu projektach i zarazem rozwijać.

Oczywiście w utrzymaniu pomocny jest svn, ale z drugiej strony wiadomo, że przy każdym projekcie dochodzi coś nowego i coś trzeba w tych klasach poprawić/pozmieniać. I teraz jak tym wszystkim zarządzać?

Ja wymyśliłem pewne rozwiązanie i chciałbym skonfrontować je z waszymi doświadczeniami

Załóżmy, że mam 3 projekty

lib - klasy wspólne do wielokrotnego użytku
pro1 - projekt 1
pro2 - projekt 2

Teraz teraz w lib tworze 2 galezie -> dla każdego projektu po jednej i robie ich checkout jako folder do obu projektów. Pracuje sobie spokojnie na obu projektach i tam też rozwijam moje klasy wspólne. Następnie po pewnym czasie robie w lib połączenie danej gałęzi z trunkiem i importuje tam, to co uznam za krok w dobrą stronę, natomiast resztę zmian odrzucam i traktuje jako "personalizację" w danym projekcie.

Szczerze mówiąc jest to jedyne wyjście jakie mi przychodzi do głowy i nie wiem czy jest ono dobre? Co o tym myślicie. Na forum pro widziałem podobny temat (już niestety zamknięty) i tam proponowano użycie external - szczerze mówiąc nie mogę się jednak połapać po wstępnym przeczytaniu dokumentacji o co chodzi - może od rana pójdzie lepiej.

No nie ważne - będę wdzięczny za każde sugestie.

External jest najlepszym rozwiązaniem.

U nas rozwiązaliśmy to mniej więcej tak:


Gdzie /lib/ to biblioteki zewnętrzne, ./core/ to pliki "systemowe" tworzonych przez nas projektów a ./project/ to pliki personalizowane na potrzeby każdego projektu.

W /tags/ tworzone są natomiast kopie jakichś "stabilnych" etapów projektu, np. związanych z pokazaniem / oddaniem / uruchomieniem go u klienta.

Z tego co widzę, to w każdym projekcie macie checkout z trunka lib. Też myślałem o takim rozwiązaniu, ale dzięki temu w każdym projekcie rozwijacie niejako również lib. Wiadomo, że skoro robicie wiele projektów, to wasze lib jest już w miarę stałe, ale załóżmy, dochodzą jakieś zmiany - po ich commicie wszystkie pozostałe projekty też mają te zmiany, co nie zawsze jest tym co chciałbym osiągnąć - mogą pojawić się pewne nieprzewidziane efekty uboczne w pozostałych projektach. Moje klasy wspólne nie mają jeszcze zamrożonego API, ba w zasadzie są na etapie testów praktycznych - chce je rozwijać wraz z praktycznymi projektami, żeby zobaczyć czego w nich brakuje.

Z drugiej strony łatwiej wam przekazywać poprawki między innymi projektami. W moim rozwiązaniu, gdy w gałęzi pojawia się jakaś poprawka, to najpierw muszę ją przerzucić do trunka mojego lib a potem dopiero do innej gałęzi danego projektu.

Tych externali jakąś nie mogę pojąć po lekturze svn book - niby to stosuje teraz, ale nie mogę powiedzieć, żebym czuł komfort... Działam trochę po omacku - muszę gdzieś o tym doczytać jeszcze.