Co zrobić z wieloma projektami w zależności od tego samego źródła?

Question

To jest coś, z czym spotkałem się dwa razy w ciągu ostatniego miesiąca i nie jestem nawet pewien, jak to sformułować jako zapytanie Google.

Używam SVN do tego wszystkiego, ale wygląda na to, że powinien to być ogólny problem z wersjami.

Mamy dwa projekty, a jeden z nich zależy od kodu drugiej osoby. Z powodu problemów z interfejsem API, nie jest pragmatyczne posiadanie jakiejś formy powiązania między produktami (i nie chcę konfigurować wszystkich maszyn nie-koderów, aby to działało).

Wyobrażam sobie, że jeśli wstawię kopię wspólnego kodu do struktury katalogów, w końcu nadpisam wszystkie pliki konfiguracyjne, których używa SVN. Oznaczałoby to, że wersja w katalogach projektu zależnego nie będzie już mogła być aktualizowana.

Ex:

Projekt nr 1 musi wykorzystać MyExampleClass klasy, jednak MyExampleClass jest czymś, co określa się jako część i potrzebne Project # 2.

Answer 1

Look w svn:externals

Answer 2

umieścić wszystkie udostępnione pliki w osobnym folderze na jeden z projektów lub w oddzielnym drugim. Następnie użyj externals, aby odwołać się do tego folderu. Mieszanie plików z różnych miejsc w tym samym folderze jest złym pomysłem.

Answer 3

svn: externals pozwala na wprowadzanie plików na poziomie katalogu. Jak:

Proj1\ 
    File1 
    File2 

Proj2\ 
    File3 
    File4 

Następnie w proj2 można svn: externals proj1, a kończy się z:

Proj2\ 
    Proj1\ 
    File1 
    File2 
    File3 
    File4 

teraz, jeśli chcesz mieć pliki z 2 projekty w 1 folderze jak:

Proj2\ 
    File1 <- from Proj1 
    File2 <- from Proj1 
    File3 
    File4 

Wtedy nie sądzę, że SVN to obsługuje.

Jednakże pracowałem z innymi narzędziami do kontroli źródła, które umożliwiają "łączenie" jednego pliku z jednego projektu do drugiego w dowolnym miejscu (w szczególności Borland StarTeam).

Answer 4

Od kilku lat używamy w praktyce svn:externals wskazującego na współdzielony kod. Mieliśmy z tym kilka interesujących problemów, które powinieneś rozważyć przed użyciem. Oto struktura że mamy:

root 
+---common 
| +---lib1 
| | \---trunk 
| |  +---include 
| |  \---src 
| \---lib2 
|  \---trunk 
|   +---include 
|   \---src 
+---proj1 
| \---trunk 
|  +---include 
|  | \---common 
|  \---src 
|   \---common 
\---proj2 
    \---trunk 
     +---include 
     | \---common 
     \---src 
      \---common 

W common katalogi zarówno include i src w projekcie zawierają definicje zewnętrznych, które ciągnąć w pomieszczeniach biblioteki:

c:\dev> svn pget -v svn:externals proj1\trunk\src\common 
Properties on 'c:\dev\proj1\trunk\src\common': 
    svn:externals : lib1 http://.../common/lib1/trunk/src 
        lib2 http://.../common/lib2/trunk/src 

Problem, który mamy uruchomić w to wieloaspektowe, ale związane z tagowaniem i rozgałęzianiem naszego źródła, ponieważ projekty zmieniają się w czasie. Definicja externals że pokazałem powyżej ma kilka dość poważne problemy, jeśli chcesz mieć powtarzalne buduje:

1. To odnosi się do dynamicznego docelowego - trunk.
2. Nie odnosi się to do jednoznacznej wersji.

Podczas rozgałęzienia za pomocą svn copy, zewnętrzne są kopiowane dosłownie, ponieważ są one naprawdę tylko właściwościami dołączonymi do obiektu. Niektóre inne komendy svn (commit, checkout i export) faktycznie interpretują właściwości. Kiedy tagujesz projekt, naprawdę chcesz zachować stan projektu przez cały czas. Oznacza to, że musisz "przypiąć" zewnętrzne do konkretnej wersji, więc musisz zmienić definicję zewnętrznych na jawną, odwołując się do wersji, którą chcesz (np. "lib1 -r42 http://.../common/lib1/trunk/src"). To rozwiązuje jeden aspekt problemu.

Jeśli musisz zachować wiele niekompatybilnych gałęzi wspólnego kodu, musisz określić gałąź, którą chcesz jawnie wraz z (prawdopodobnie) wersją.

Nie trzeba dodawać, że może to być trochę ból głowy. Na szczęście ktoś na terenie Subversion pisze skrypt svncopy.pl, który automatyzuje część tego bałaganu. Wciąż jesteśmy (i byliśmy) zmagający się z niektórymi trudnościami, które to wspierają w dziedzinie wdrożonego produktu z paczką wspólnego kodu i mandatem trzech różnych wersji w terenie w dowolnym momencie.

Jeśli zdecydujesz się na tę trasę, pamiętaj o tym, jak zachować powiązania w miarę rozwoju i zmian projektu. Przekonaliśmy się, że odrobina czasu na myślenie nad procesem będzie tutaj długa.

Answer 5

zewnętrznymi, ale zdawać sobie sprawę z tego problemu:

Subversion update externals to a date