Połącz gałąź z pniem

125

Mam szczególny problem z SVN merge. Chcę połączyć się z gałęzi deweloperskiej do głównej. Mamy kilka gałęzi deweloperskich odciętych jednocześnie.

Scalam jedną z tych gałęzi do linii głównej za pomocą tego polecenia:

svn merge trunk branch_1

Widzę zmiany, które nie są częścią tej gałęzi, są scalane w trunk. Co ja robię źle ?

Wersja SVN:

Klient wiersza polecenia Subversion, wersja 1.6.16-SlikSvn-tag-1.6.16@1076804-WIN32.

svn version-control merge Vanchinathan Chandrasekaran
źródło
7
Wiem, że to nie jest odpowiedź, ale jeśli masz kilka aktywnych gałęzi jednocześnie, prawdopodobnie lepiej przenieś się do Mercurial lub Git. Ps: Nie jestem fanatykiem, pracuję z svn ~ 7 lat ;-)
zerkms
2
Jakie korzyści daje? Dlaczego przejście na Git lub Mercurial to lepszy wybór?
Vanchinathan Chandrasekaran
3
ponieważ git i mercurial mają znacznie lepsze wsparcie dla gałęzi. Zalety: nie będziesz zadawał takich pytań i będziesz miał mniej bólu głowy przy tworzeniu i utrzymywaniu oddziałów (obecnie pracuję w projekcie z> 1000 oddziałów, w svn było piekło z nimi pracować)
zerkms
Zalecam zajrzenie do Svnmerge.py i przejrzenie tego artykułu .
chown

Odpowiedzi:

215

Twoja svn mergeskładnia jest nieprawidłowa.

Chcesz wyewidencjonować kopię roboczą, trunka następnie skorzystać z svn merge --reintegrateopcji:

$ pwd
/home/user/project-trunk

$ svn update  # (make sure the working copy is up to date)
At revision <N>.

$ svn merge --reintegrate ^/project/branches/branch_1
--- Merging differences between repository URLs into '.':
U    foo.c
U    bar.c
 U   .

$ # build, test, verify, ...

$ svn commit -m "Merge branch_1 back into trunk!"
Sending        .
Sending        foo.c
Sending        bar.c
Transmitting file data ..
Committed revision <N+1>.

Więcej informacji można znaleźć w rozdziale książki SVN o scalaniu .

Zwróć uwagę, że w momencie pisania była to właściwa odpowiedź (i została zaakceptowana), ale sprawy potoczyły się dalej. Zobacz odpowiedź topek i http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate

blahdiblah
źródło
4
- opcja reintegrate nie jest obowiązkowa, gałąź (w wersji 1.6) może być połączona z dowolnym miejscem docelowym dowolną liczbę razy
Lazy Badger
1
Naprawdę? Bez ryzyka ponownego utworzenia tych samych zestawów zmian? Czy może Pan podać link do potwierdzających tego dowodów?
Neutrino
--reintegratenie jest rzeczywiście obowiązkowe, ale w tym przypadku naprawdę zalecane. Próbowałem to zrobić bez --reintegratei zakończyłem setkami konfliktów. Bez --reintegratekonfliktów i wszystko było dobrze!
tibo
17
Ta --reintegrateopcja jest prosta i skuteczna, ALE należy zauważyć, że „Po wykonaniu --reintegratescalenia z gałęzi do pnia gałąź nie nadaje się już do dalszej pracy. Nie jest w stanie poprawnie wchłonąć nowych zmian pnia ani nie można jej poprawnie ponownie zintegrować do bagażnika ”. jak wyjaśniono w książce, do której masz link.
Pino,
3
@daveL, forward scala z pnia do gałęzi ma dla mnie sens. Jednak znalazłem zaawansowaną funkcję, która „utrzymuje przy życiu ponownie zintegrowaną gałąź” (patrz stackoverflow.com/a/10163059/685806 ), a ponadto jest stosowana automatycznie przez nowsze wersje klienta.
Pino
78

Jeśli twój katalog roboczy wskazuje na linię główną, powinieneś być w stanie połączyć swoją gałąź z:

svn merge https://HOST/repository/branches/branch_1

pamiętaj, aby wydać to polecenie w katalogu głównym swojego łącza

topek
źródło
7
Od SVN 1.8. to jest właściwa odpowiedź. Zobacz subversion.apache.org/docs/release-notes/ ...
GreenAsJade
@blahdiblah fragment kodu zawiera wiele dodatkowych informacji. Istnieje powód, dla którego streszczenie badań jest odczytywane o rzędy wielkości bardziej niż jakakolwiek inna część badania. To samo dotyczy testów UX, minimalizowania współczynników odrzuceń itp. To ta sama zasada.
ahnbizcad
w wersji 1.7 można było scalać bez opcji --reintegrate, rozwijać się w gałęzi i kontynuować scalanie. Niestety, 1.8 zmusi to do ponownej integracji i wydaje się, że nie ma sposobu, aby temu zapobiec. Oznacza to, że gdy tylko się połączysz, nie możesz użyć tej gałęzi bez przechodzenia przez przerażający "taniec utrzymania przy życiu"
John Little
3
Nie zapomnij o wysłaniu kopii roboczej z powrotem do repozytorium po scaleniu!
John
16

Wykonaj aktualizację svn w bagażniku, zanotuj numer wersji.

Z bagażnika:

svn merge -r<revision where branch was cut>:<revision of trunk> svn://path/to/branch/branchName

Możesz sprawdzić, gdzie gałąź została wycięta z pnia, wykonując dziennik svn

svn log --stop-on-copy
Mike K.
źródło
Ponieważ istnieje wiele gałęzi deweloperskich, które działają w tym samym czasie, to również nie działało dla mnie, to polecenie pobierało również zmiany z innych gałęzi. Może to problem z klientem SLik SVN?
Vanchinathan Chandrasekaran
Chociaż nie jest to niedokładne, istnieją łatwiejsze sposoby na połączenie z nowszymi wersjami svn(takimi jak ta, której używa OP).
blahdiblah
@VanchinathanChandrasekaran, w poleceniu określasz nazwę gałęzi, ponieważ svn://path/to/branch/branchNamepowinno to pobierać tylko zmiany z tej gałęzi, a nie z innych gałęzi. Jeśli tak, to grozi nam niebezpieczeństwo!
Fredrick Gauss
1

Składnia jest nieprawidłowa, a powinna być

svn merge <what(the range)> <from(your dev branch)> <to(trunk/trunk local copy)>
lwpro2
źródło