2009-04-16 78 views
11

Mamy kilka dużych podprojektów wewnątrz głównego katalogu głównego SVN.
Zatwierdzam i scalam tylko mój podprojekt podczas pracy z naszymi oddziałami, głównie dlatego, że jest szybszy.Przyjmuje i łączy w podkatalogach SVN za szkodliwe?

Jednak kolega zauważył ten reference to merging subdirectories in Version Control with Subversion (aka „SVN Book”):

Niestety, jest to zakres ostrzeżenia. Powiązana sekcja również nie wyjaśnia.

Czy popełnianie i łączenie podkatalogów SVN jest szkodliwe dla oddziałów zwalniania?
A co z krótkimi oddziałami obiektów?

+0

Podoba mi się tytuł :) – Dunaril

Odpowiedz

14

Jednym z możliwych wyjaśnień jest to, że można zapomnieć o częściach zestawu zmian.

Jeśli zmiana powoduje, że łączysz pliki okładek spoza podkatalogu, który wypisałeś, zawsze istnieje możliwość, że zapomnisz scalić te pliki.

Na przykład, jeśli masz popełnić tak na pniu:

r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 

Change some stuff 

I wtedy mają kasę z podkatalog1 z oddziału „stable”, a następnie można scalić zmiany zestawu r5 tak:

$ svn co http://example.com/svn/branches/stable/subdir1 
$ cd subdir1 
$ svn merge -c 5 http://example.com/svn/trunk/subdir1 . 
--- Merging r5 into '.': 
U main.c 
$ svn ci -m"Merged r5 from trunk" 

Ale to będzie łączyć tylko połowę rewizji 5. co gorsza, jeśli wrócić i spojrzeć na logu, to teraz pokazać to:

$ svn log -g http://example.com/svn/ 
... 
------------------------------------------------------------------------ 
r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 
Merged via: r6 

Change some stuff 

Wygląda na to, że połączyłeś całe zatwierdzenie, gdy w rzeczywistości scaliłeś tylko niektóre z nich. Oczywiście r6 pokazuje, że tylko 1 plik został zmieniony w stabilnym oddziale.

------------------------------------------------------------------------ 
r6 | rich | 2009-04-16 22:28:16 +0200 (Thu, 16 Apr 2009) | 1 line 
Changed paths: 
    M /branches/stable/subdir2 
    M /branches/stable/subdir2/main.c 

Merge revision 5 from trunk 

Ktoś musi pamiętać, lub informacja, że ​​tylko część zestawu zmian, ale połączone, a reszta musi robić. Brak łączenia podkatalogów pozwala uniknąć tego problemu.

Są chwile, kiedy naprawdę nie chcesz scalić wszystkich poprzednich zatwierdzeń, a powyższy scenariusz jest dokładnie tym, co zamierzałeś zrobić. W takim przypadku prawdopodobnie najlepiej jest dodać dobrą wiadomość zatwierdzającą opisującą twoje intencje.

+1

+1 - Świetna odpowiedź i przykład –

1

Zatwierdzanie nie powinno sprawić problemu, ale scala ścieżki SVN, co jest i nie jest scalone.

Dlatego zakładam, że chcesz scalić w katalogu głównym, aby uprościć przyszłe scalenia (w stosunku do rozmiaru zestawu danych porównywany przez SVN).

1

Dla wersji subversion poprzedzających 1.5, scalanie podkatalogów spowodowało późniejsze scalenie reszty drzewa katalogów naprawdę skomplikowane. Po scaleniu katalogu svn po prostu zastosował wszystkie zmiany dokonane w tym katalogu do drugiej gałęzi.Jeśli już scaliłeś podkatalog, a następnie próbowałeś scalić katalog główny, wszystkie zmiany w podkatalogu znajdowały się już w gałęzi docelowej (od kiedy zostały one scalone wcześniej). Svn teraz nie wiedział, że te zmiany były z wcześniejszego scalenia, po prostu zobaczył, że były rzeczy "na drodze", kiedy próbował scalić podkatalog, powodując wiele konfliktów.

Aby tego uniknąć, musiałbyś zadbać o scalenie tylko tych katalogów, których wcześniej nie scaliłeś, co znacznie skomplikowało cały proces. Trzeba dokładnie zapamiętać, które wersje podkatalogów już połączono i zastosować tylko pozostałe zmiany pozostałych katalogów/wersji. Może to być mylące. Zawsze łączenie całego oddziału ułatwiało to. Obecne wersje subversion śledzą wcześniejsze scalenia wewnętrznie, dzięki czemu można uniknąć tych problemów.

Zatwierdzanie podkatalogów nie stanowi problemu. Dla svn jest to zwykła, globalna wersja repozytorium. W tej wersji będą tylko zmiany w jednym podkatalogu, ale dla svn nadal jest to nowa wersja całego repozytorium, tak jak każde inne zatwierdzenie.

+2

W svn 1.5+ tak nie jest. Scalenie podkatalogu, a następnie połączenie reszty tego samego zatwierdzenia z katalogu głównego nie "ponownie scala" elementów już scalonych w podkatalogu powodującym konflikt. Właściwość svn: mergeinfo zapobiega temu. – richq

+0

Miło to słyszeć. To naprawdę sprawiło, że subwersje łączą się niepotrzebnie i denerwująco skomplikowane, do punktu bezużyteczności. – sth

5

Innym powodem może być to, że połączenie tylko z rootem ogranicza liczbę właściwości svn: mergeinfo, które zostaną ustawione w folderach/plikach w twoim repozytorium.

+0

Twoja odpowiedź jest bardziej zgodna z duchem mojego pytania. Mam przeczucie, że skoro nasze podprojekty mają tylko jeden poziom głębokości, ustawienie mergeinfo na jednym z nich byłoby rozsądne. – mskfisher