Jak uniknąć dużej liczby svn: mergeinfo podczas scalania tułowia do oddziału w funkcje w SVN

Question

Próbuję utrzymać gałąź funkcji na bieżąco poprzez połączenie tułowia do oddziału. Problem polega na tym, że około 2000 plików, które istniały, gdy gałąź została utworzona, i które pozostały nietknięte w gałęzi i na magistrali, są aktualizowane bez niczego poza svn: mergeinfo. Projekt jest dość dużą skalę, a także ich wpływ na naszą historię SVN jest tak duża, że ​​czyni scalającej historię bezużyteczny, ponieważ jest oznakowanie dosłownie tysiące plików zmieniły, choć jedyną zmianą tych plików odbywa się przez Sam SVN.

Próbowałem

• Stosując tę ​​samą wersję klienta jako Repo (1.5.2)
• Korzystanie z moją aktualną wersję klienta 1.6.10
• Scalanie szereg zmian, od początku do oddziału główka

Powinienem wspomnieć, że uważnie przyglądałem się dokumentacji SVN, próbując tego. Więc żadne reguły nie powinny być łamane (np. Bez włączonych poddrzew, czysta kopia lokalna itp.)

Answer 1

Bascially oczyścić repozytorium trzeba uruchomić następujące na oddziale integracyjnym tak, że fani zmiana stamtąd: -

C:> svn propdel svn: mergeinfo -R

tj Ciebie zrób to w bagażniku, aby przyszłe wersje i gałęzie funkcji nie były zanieczyszczone. Podczas łączenia istniejących gałęzi możesz zignorować wszystkie zmiany svn: merginfo poniżej "scalania root", ponieważ i tak będą one dziedziczone.

pisałem bloga na ten temat jakiś czas temu, który obejmuje ją bardziej szczegółowo: -

Czyszczenie svn: mergeinfo odchody http://chrisoldwood.blogspot.com/2010/03/cleaning-up-svnmergeinfo-droppings.html

Answer 2

Jeśli posiadasz takie informacje o plikach, które tak naprawdę nie zostały zmienione, to Ty lub ktoś inny nie łączy się z korzeniami kopii roboczej. Jedynym rozwiązaniem jest usunięcie svn: mergeinfo z plików, ponieważ jedyna lokalizacja znajduje się w katalogu głównym kopii roboczej nigdzie indziej. I jeszcze jeden punkt, w którym należy zaktualizować repozytorium do wersji 1.6.X ..

Answer 3

svn doda właściwości mergeinfo do pojedynczych plików, jeśli ich historia scalania różni się od historii ich katalogu nadrzędnego. Gdy to się stanie, każde kolejne scalenie, niezależnie od tego, jak nieszkodliwe, spowoduje zaktualizowanie tych właściwości mergeinfo. Uważam, że pierwsza połowa this article jest pomocna w zrozumieniu, dlaczego tak się dzieje.

Jeśli chcesz uniknąć tych ciągłych zmian mergeinfo, będziesz musiał „posprzątać” istniejące właściwości mergeinfo na swoim oddziale. Najbezpieczniejszym, ale najbardziej pracochłonnym sposobem jest uruchomienie svn propget -R svn:mergeinfo na gałęzi, a następnie zbadanie różnic między mergeinfo na poszczególnych plikach i mergeinfo ich katalogu nadrzędnego. Może się okazać, że różnice są niewielkie i że "svn scalenie" małej liczby pojedynczych wersji będzie wystarczające do wyzwolenia elgeinfo elision, powodując zniknięcie wszystkich indywidualnych właściwości mergeinfo.

Jeśli jesteś przekonany, że rozumiesz jak mergeinfo działa, można też po prostu przebrnąć i ręcznie edytować lub usunąć mergeinfo z plików przestępczych.

Answer 4

Ponieważ nie jestem przekonany, ze skreślenia svn:merge-info własności ślepy, I zaimplementowałem narzędzie do analizy obecnej sytuacji na kopii roboczej i usunięcia jak najwięcej scalonych wersji z właściwości spoza katalogu głównego merge-info. Po dodatkowych kontrolach i kontrolach ludzkich można zatwierdzić zmiany w kopii roboczej.

Oto ona: svn-clean-mergeinfo

Nie wahaj się zgłosić sprawę o jego użytkowania, aby uzyskać to poprawić.