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

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