Dlaczego pojawiają się konflikty podczas łączenia gałęzi z pnia, a następnie łączenia z powrotem do gałęzi?

Powiedzmy, że mam gałąź funkcji o nazwie "branches/BigFeature". Chcę wprowadzić zmiany w Pniu, wprowadzić pewne zmiany w Trunk i połączyć je z powrotem w gałąź "BigFeature", aby rozwój mógł być kontynuowany.Dlaczego pojawiają się konflikty podczas łączenia gałęzi z pnia, a następnie łączenia z powrotem do gałęzi?

moje kroki były:

Merge najnowsze zmiany w bagażniku do gałęzi/BigFeature. (Żółw SVN -> Scal szereg poprawek)
Scal zmiany w gałęziach/BigFeature na Trunk. (Żółw SVN -> Ponownie zintegruj oddział)
Wprowadź zmiany w bagażniku.
Połącz zmiany w gałęzi z gałęziami/dużymi cechami. (Tortoisesvn -> Merge szereg korekt)

Problem pojawia się w punkcie 4. Kiedy scalić z powrotem do BigFeature uzyskać wszelkiego rodzaju konfliktów. Wydaje się, że ma problem z plikami, które zostały pierwotnie dodane w gałęziach/BigFeature, ale zostały scalone z Trunk.

Komunikat daje mi to „Ostatni operacja scalania próbował dodać plik «bla», ale został już dodany lokalnie.

to trochę sens, ponieważ plik był pierwotnie dodany w gałęzi/gałąź BigFeature, a następnie połączony z Trunk, ale dlaczego operacja łączenia nie może tego zrobić? Dlaczego pojawia się jako konflikt?

Ten sam rodzaj błędu występuje w przypadku usuniętych plików

Ostatnia operacja scalania próbowała usunąć/przenieść/zmienić nazwę katalogu "blah", ale została usunięta, przeniesiona lub zmieniona lokalnie.

Dzięki za pomoc.

Źródło

2010-06-07 Justin

SVN scalania w ogóle nie działa dobrze. – alternative

Czy istnieją alternatywy? – Justin

Każdy, kto mówi, że svn merge nie działa, nie robi tego dobrze. Konceptualny pogląd Svn na zmiany nie jest najlepszy (później SCMy, takie jak git, nieco zbliżyły się do znaku), ale nie jest prawdą, że nie można łączyć się z subwersją, a nawet zarządzać skomplikowanym kodem z połączeniami nadchodzącymi w I NA zewnątrz. – Ether

Niestety jest to niedobór svn, sposób w jaki jest zbudowany.

Kroki w SVN musi wyglądać następująco:

1. (not modified) Merge the latest changes in Trunk to branches/BigFeature. (Tortoise SVN -> Merge a range of revisions) 
2. (not modified) Merge the changes in branches/BigFeature to Trunk. (Tortoise SVN -> Reintegrate a branch) 

2a. Delete branch branches/BigFeature 
2b. Create branch branches/BigFeature from current trunk 

3. (not modified) Make some changes to Trunk. 
4. (not modified) Merge the changes in Trunk to branches/BigFeatures. (Tortoise SVN -> Merge a range of revisions)

SVN oddział nie jest użyteczny po pracy reintegracji.

Aktualizacja: istnieje second way, zamiast usuwania gałęzi.

2a. on branch: 
    $ svn update 
    Updated to revision X 
    $ svn merge --record-only -c X ^/trunk 
    $ svn commit -m "Block revision X from being merged into the branch."

Nie znałem tej sztuczki, ja dowiedziałem się dzięki swoim pytaniu: D

Źródło

2010-06-07 22:03:33 silk

To niefortunne. Ale hej przynajmniej to nie tylko ja :) A ta praca powinna załatwić sprawę. – Justin

Nie trzeba usuwać i odtwarzać gałęzi przez cały czas. Musisz tylko odpowiednio skonstruować komendę scalania, aby nie scalić ponownie wszystkich scalonych elementów. – Ether

Czy możesz podać pewien wgląd, jak to zrobić? Jestem w porządku z linią cmd, ale oczywiście wolałbym, gdyby SVN Tortoise zapewnił środki do tego. – Justin

Dlaczego pojawiają się konflikty podczas łączenia gałęzi z pnia, a następnie łączenia z powrotem do gałęzi?

Odpowiedz

Powiązane problemy