Usuń niepotrzebne właściwości svn: mergeinfo

136

Kiedy łączę rzeczy w moim repozytorium, Subversion chce wiele dodać / zmienić svn:mergeinfo właściwości do plików, które są całkowicie niezwiązane z rzeczami, które chcę scalić.

Pytania dotyczące tego zachowania zostały zadane wcześniej w witrynie Stack Overflow:

Z tego, co rozumiem z tematów wymienionych powyżej, wygląda na to, że wiele plików w moim repozytorium ma określone svn:mergeinfowłaściwości, podczas gdy nie powinny. Zaleca się zmniejszenie ilości i umieszczanie tych właściwości tylko w odpowiednich plikach / folderach.

A teraz moje pytanie: w jaki sposób mogę łatwo usunąć te niepotrzebne właściwości? Używam TortoiseSVN, ale nie chcę ręcznie sprawdzać / naprawiać setek plików. Czy istnieje łatwiejszy sposób na usunięcie tych niepotrzebnych svn:mergeinfowłaściwości?

PS Ja nie szukam C ++ SVN kodu API.

LeonZandman
źródło

Odpowiedzi:

142

Oto inny sposób usunięcia wszystkich właściwości svn: mergeinfo podrzędnego drzewa, ale nie w folderze głównym (jest to potrzebne do prawidłowego działania rozgałęzień).

Z katalogu głównego projektu wykonaj:

svn propdel svn:mergeinfo -R
svn revert .
svn ci -m "Removed mergeinfo"
Vincent
źródło
57
Lub po prostu nie rób tego w katalogu głównym "svn propdel -R svn: mergeinfo ./*"
JeremyWeir
3
"svn propdel -R svn: mergeinfo ./* ./.[^.]*" jeśli masz również ukryte pliki "dot" / * ix, prawdopodobnie nie stanowi to problemu dla użytkownika Windows na pytanie.
Peter
3
tłumienie wyjścia przyspiesza to: "svn propdel svn: mergeinfo -R> nul" (lub> / dev / null w Linuksie)
bebbo
2
@JeremyWeir Co masz na myśli mówiąc „po prostu nie rób tego w katalogu głównym”? Skąd więc? Masz wiele pozytywnych głosów pod tym komentarzem, ale nie widzę alternatywy.
TT.
3
@TT. Myślę, że chodzi o to, aby po prostu przejść do katalogu zawierającego wszystkie pomieszane informacje o scalaniu i zrobić to stamtąd, aby nie trzeba było przywracać katalogu głównego. Nie chcesz mieszać informacji o połączeniu katalogu głównego.
JeremyWeir
15

Oto sposób na usunięcie wszystkich właściwości poddrzewa svn: mergeinfo. Uruchom go w katalogu głównym repozytorium:

svn propget svn:mergeinfo --depth=infinity 
    | grep -v "^/"
    | grep -v "^\."   
    | cut -d- -f1 
    | xargs svn propdel svn:mergeinfo

Wszystko w jednej linii dla łatwego kopiowania / wklejania:

svn propget svn:mergeinfo --depth=infinity | grep -v "^/" | grep -v "^\." | cut -d- -f1 | xargs svn propdel svn:mergeinfo

Aby zobaczyć, które pliki to zadziała, przed jego uruchomieniem, zmień ostatni „propdel” na „propget” lub całkowicie usuń ostatni potok xargs.

kelwin
źródło
2
Działa z myślnikami w plikach: svn propget -R svn: mergeinfo | grep -v "^ /" | grep -v "^ \." | wytnij "-d" -f1 | xargs svn propdel svn: mergeinfo
Squirrel
12

Jak wspomniano w tym wątku :

  • Większość pustych informacji o scaleniu („pustych”) może być spowodowanych przez kopię roboczą do kopii / przeniesień kopii roboczej, gdy element źródłowy nie ma jawnych informacji o scaleniu. Używanie propdel może być rozwiązaniem, chyba że używasz 1.6 SVN: od 1.5.5 te kopie WC-to-WC nie tworzą już pustych informacji o połączeniu w miejscu docelowym
  • wcześniejsza operacja restrukturyzacji przeniesienia svn (zmiany nazwy) może również propagować informacje o merge, zamiast pozostawiać je w katalogu głównym
  • istnieje potencjalny problem z pamięcią, śledzony według przypadku 3393, który zostanie naprawiony w nadchodzącej wersji 1.6.2 i przeniesiony z powrotem w 1.5
VonC
źródło
6

Ponieważ nie jestem pewny ślepych svn:merge-info usuwania właściwości, zaimplementowałem narzędzie do analizy bieżącej sytuacji na kopii roboczej i usunięcia jak największej liczby wersji scalania z właściwości informacji o scalaniu innych niż root. Po dodatkowych sprawdzeniach i kontrolach przez człowieka zmiany w kopii roboczej mogą zostać zatwierdzone.

Oto ona: svn-clean-mergeinfo

Nie wahaj się zgłaszać żadnych problemów dotyczących jego użytkowania, aby go ulepszyć.

Subversion 1.10 wprowadza nowe narzędzie dedykowane temu zadaniu: svn-mergeinfo-normalizer

Yves Martin
źródło
2
To narzędzie doskonale nadaje się do konsolidowania właściwości informacji o scalaniu, takich jak rodzaje, które są tworzone z częściowymi scaleniami podkatalogów, które mogą tworzyć znacznie mniej niż doskonale skoordynowani programiści w dużym zespole. Wydaje się, że narzędzie ma problem z plikami, które nie istnieją w każdej gałęzi, otrzymuję resztki właściwości informacji o scalaniu w plikach wskazujących na wersje w gałęziach, w których plik nigdy nie istniał.
davenpcj
Zgadzam się, że nie jest doskonały… dlatego nadal wymagane są „kontrole i kontrole przez człowieka”. W twoim przypadku, jeśli zidentyfikowałeś nieistotne zmiany we właściwościach informacji o scalaniu, możesz usunąć te wersje lub całą właściwość svn: merge-info z tych plików przed zatwierdzeniem. Użyj github, aby poprosić o ulepszenia.
Yves Martin
4

Wiem, że minęło trochę czasu, ale napotkałem podobny problem. Używam TortoiseSVN 1.6.7. Tak się złożyło, że właściwość znajdowała się w katalogu głównym mojej kopii roboczej. Kiedy przeglądałem właściwości w katalogu głównym i kliknąłem Usuń na svn: mergeinfo, zapytał mnie, czy chcę usunąć go rekurencyjnie. Pozbyło się to wszystkich moich błędów svn: mergeinfo.

moribvndvs
źródło
Byłem w takiej samej sytuacji. Pracował dla mnie. Dzięki!
andrewd18
2

Jeśli jesteś pewien, że chcesz masowo usunąć właściwości informacji o scalaniu, możesz użyć następującego skryptu BASH.

FILES=`svn status |grep "^ M      " |sed s/" M      "// |tr '\n', ' '`
svn revert $FILES

Pobiera listę zmienionych plików, filtruje ją, aby po prostu scalać informacje tylko o zmianach, usuwa wszystko oprócz rzeczywistej ścieżki pliku, konwertuje ścieżki jeden w wierszu na listę rozdzielaną spacjami, a wywołania wracają na tę listę.

Ścigaj Seiberta
źródło
2
Dzięki, ale jak mogłeś ode mnie wiedzieć, wspominając o TortoiseSVN, jestem użytkownikiem Windows i nie używam powłoki Bash :-)
LeonZandman
To samo powinno być możliwe w DOS, choć prawdopodobnie nie tak zwięzłe.
Chase Seibert
1
Czy to nie przywraca tylko plików ze zmodyfikowanymi informacjami o scalaniu w bieżącym katalogu roboczym? Jeśli tak, to nie rozwiązuje problemu: istniejące jawne informacje o połączeniu. W tym celu musiałbyś jechać.
Dominic Scheirlinck
2
To jest dość błędne - czy masz nazwę pliku ze spacjami w nazwie? Ze znakami glob w nazwie? W obu przypadkach złe wieści. Zatwierdzonym / obsługiwanym sposobem parsowania danych wyjściowych ze statusu svn jest użycie --xmlflagi i parsera XML; wszystko inne może się zmienić między wersjami, ponieważ zgodność w przód tekstowego formatu wyjściowego nie jest gwarantowana.
Charles Duffy,
2

Zamiast po prostu usuwać na ślepo właściwości informacji o scalaniu, możliwe jest również dokończenie „brakujących” scaleń.

Skopiuj właściwość mergeinfo z folderu głównego, a następnie wykonaj scalanie w folderze podrzędnym dla odpowiedniej ścieżki względnej i dokładnie tej samej listy wersji. (Możesz, ale nie musisz, wymieniać tylko różnice między tą listą a listą już w folderze podrzędnym.)

Zwykle to scalanie powinno kończyć się tylko zmianą właściwości informacji o scaleniu, a nie rzeczywistych plików. (Jeśli w końcu zmieni się pliki, to jedno z poprzednich scaleń musiało być tylko częściowym scaleniem, które i tak mogło powodować problemy).

Powinno to skończyć się usunięciem właściwości mergeinfo, po uzyskaniu ich dokładnego dopasowania. Konieczne może być również wykonanie odwrotnej czynności: scal w katalogu głównym wszelkie wersje scalające obecne tylko w folderze podrzędnym (ponownie możesz po prostu wkleić pełną listę i pozwolić SVN znaleźć dla Ciebie różnice).

Miral
źródło
1

Aby dokonać zmian w strukturze katalogów, wyglądałoby to następująco (tylko funkcja wyszukiwania w systemie innym niż DOS):

find . -path "*/.svn" -prune -or -exec svn propdel svn:mergeinfo '{}' \;

Uruchamiam klienta 1.6.12 podłączonego do serwera 1.5, mam podobny problem; nie jest to podkatalog w projekcie, który potrzebuje własnego svn: mergeinfo, ale o 121 takich wpisów (w tym 5 katalogów poniżej ./var z „svn: ignore *”) wydaje się nieco niestosowne. Dlatego byłoby miło mieć skrypt (np. W Pythonie), który jest w stanie usunąć oczywiście zbędne informacje o scalaniu i powiedzieć o innych różnicach ...

Tobias
źródło