Podejrzewam, że mam uszkodzony plik mergeinfo, ale nie jestem pewien. Czy ktoś wie, w jaki sposób podjąłem decyzję i jakie zasoby są dostępne, aby pomóc rozwiązać problemy?Jak ustalić, czy svn: mergeinfo jest uszkodzony i jak mogę to naprawić?
Oto problem. Niedawno mój zespół przeniósł się na zwinność i wykorzystuje gałęzie funkcjonalne (gałęzie fabularne naprawdę), w których różne zespoły pracują jednocześnie nad tymi samymi źródłami. Gdy historia osiąga wysoki stan gotowości, zespół łączy się z pniem. Fuzje trwają dni lub tygodnie z powodu brakujących zmian, nieoczekiwanych zmian i konfliktów. Mówimy o zespołach 5-10 osób, a wysiłek/churn wydaje się być wysoki.
Ludzie użyciu wzoru tego scalania a) długości - połączyć tułowia-to-gałęzi rozwiązania, testowanie popełnienia b) PUSH - łączenia odgałęzienia do pnia, rozwiązać, testowanie popełnienia c) Odtworzenie odgałęzienie (lub zwykle tworzą nową gałąź fabuły i porzucają ją od początku)
Pod koniec tego okresu gałąź i bagażnik powinny być wyrównane.
Problemy widzimy:
- zmiany nie zgłoszone podczas tułowia do oddziału scalania pojawiają się w kolejnych branch-to-bagażniku
- konfliktów na svn: właściwości mergeinfo podczas scalania
- brak pliku, ale lokalna edycja nowego pliku dodana w oddziale i przesłana do paczki
- przychodzące + lokalne usuwanie (plik usunięty w przypadku połączeń trunkingowych i rozgałęzionych jako konflikt)
(1) Nie powinno się dziać. Pociągnięcie od gałęzi do pnia powinno zsynchronizować wszystkie zmiany już na pniu. Zmiany w scalaniu oddziału do pnia są zmianami, które zaszły na pniu. Więc w pierwszym scaleniu powinni byli propagować do oddziału, ale nie. Wskazuje to na uszkodzenie w danych mergeinfo, które "ukryłoby" zmiany trunkingu.
(2) Nie powinno się dziać. SVN powinien zarządzać zmianami w śledzeniu korespondencji seryjnej. Wskazuje to również na uszkodzenie w danych mergeinfo:
(3) Nie powinno się dziać. Jest to przypadek nowego pliku dodanego do oddziału. Powinien pojawić się jako nowy plik dodany do pnia. Wskazuje to również na uszkodzenie w danych z korespondencji seryjnej.
(4) Uważam, że jest to błąd SVN i nie możemy tego naprawić. Nadal, gdyby był to nasz jedyny problem, byłbym szczęśliwy
Jesteśmy obecnie na serwerze svn 1.5.x z klientami używającymi svn 1.6.x i svn + ssh do łączenia. Planujemy przejść do najnowszego i największego SVN, ponieważ niektóre poprawki mogą wpływać na nasze problemy.
Nadal wygląda na to, że nasze dane mergeinfo są błędne.
- Scala, które nie zgłaszają wszystkie zmiany
- konfliktów w seryjnej właściwości mergeinfo
Wszelkie dobre miejsca dla mnie, aby zacząć szukać?
Klient SVN 1.6.11 może być moją odpowiedzią. Użyłem strony uaktualnienia wandisco (która kołysze) i piekło scalania jest znacznie mniej piekielne –
Czy używasz flagi "--reintegrate" do scalenia "push"? Fakt, że masz krok "zdecydowania" po tym, jak sugeruje mi, że nie jesteś. Nie mogę znaleźć konkretnej dokumentacji mówiącej, że scalenia dwukierunkowe bez "--reintegracji" nie mogą działać, ale samo istnienie "--reintegracji" sugeruje, że połączenie svn jest inaczej nie do zadania. – slowdog