Subversion oznacza niezmodyfikowane pliki z modyfikacją

Question

Oto dziwny problem, który napotkałem przy korzystaniu z Subversion: podczas łączenia z gałęzi rozwojowej do trunk (lub z powrotem, o to chodzi) Subversion oznaczałaby wiele plików jako zmienione - podczas gdy one nie miały żadnych zmian .

Oto co się dzieje:

1. W moim oddziale zobowiązuję 1 zmodyfikowanego pliku
2. W bagażniku scalić w które popełnić
3. Dużo innych plików i katalogów są oznaczone jako „zmodyfikowane” bez faktycznie zostały zmienione (nawet białe spacje, zakończenia linii, właściwości lub tego typu rzeczy).

Technicznie, popełnienie tych niezmienionych zmian nie ma znaczenia, ale nie chcę dodawać hałasu do moich dzienników.

Każdy pomysł, co może powodować tę uciążliwość i jak temu zapobiec? Czy mogę zapytać Subversion, dlaczego plik został oznaczony jako zmodyfikowany, więc wiedziałbym, czy to zawartość pliku, właściwości itd.?

FYI: klient subversion w zakresie 1.6.x, serwer w zakresie 1,5.x. Korzystanie z wersji Versions.app i interfejsu CLI w systemie Mac OS X Leopard.

Answer 1

Co się dzieje, gdy plik/folder ma jawne mergeinfo (tj. Właściwość svn:mergeinfo), każde kolejne scalenie z odgałęzieniem spowoduje aktualizację tych informacji mergeinfo, nawet jeśli plik/folder nie jest ze sobą powiązany. Jest to naprawdę denerwujące, ponieważ wprowadza więcej bałaganu w liście zmian dla każdego scalenia.

Aby tego uniknąć, scalaj tylko z folderem "root" gałęzi, na przykład "/branches/maintenance2.x". Żaden z plików lub folderów poniżej "/branches/maintenance2.x" nie powinien wtedy uzyskać mergeinfo.Postępuj zgodnie z merging advice in the svn book.

Niestety, nawet jeśli scalisz tylko w folderze "root" gałęzi, puste właściwości svn:mergeinfo mogą nadal pojawiać się na poszczególnych plikach i folderach podczas ich kopiowania, aby wskazać, że nie otrzymały takiego samego scalenia jak ich rodzeństwo .

Jeśli scalisz tylko w katalogu głównym, prawdopodobnie bezpiecznie usuniesz zbędne poddrzewo mergeinfo. Jednym ze sposobów na to jest wykonanie rekurencyjnego usunięcia właściwości svn:mergeinfo dla każdego pliku i folderu w katalogu głównym projektu.

---

Wygląda na to, że został naprawiony w SVN 1.7. Z informacji o wydaniu: Reduced subtree mergeinfo changes.

Answer 2

Może to być pewnego rodzaju zmiana własności, ewentualnie automatyczna modyfikacja atrybutu svn: mergeinfo. Możesz sprawdzić, czy jest to modyfikacja właściwości, uruchamiając "svn stat". Jeśli "M" znajduje się w pierwszej kolumnie, to zmiany w zawartości, jeśli są w drugiej kolumnie, to zmiany właściwości.

Answer 3

Zmiana dotyczy właściwości pliku. Jeśli uruchomisz svn proplist, zobaczysz wiele wpisów mergeinfo. Dzieje się tak, ponieważ ścieżki svn łączą się we właściwościach pliku. Jest to nowa funkcja od wersji 1.5, więc nie występowała w starszych wersjach.

Nigdy nie do końca rozumiałem, z jakiego dokładnie powodu tak się dzieje, ale ma to związek z wewnętrznym wdrożeniem. Próba zrozumienia go bez zrozumienia, w jaki sposób svn jest zaimplementowany, jest, o ile się wniosłem, niemożliwa. Jednakże, zwykle główna przyczyna ma związek z pogrupowaniem poddrzewa. Na przykład. Jeśli scalisz zmiany podkatalogu lub pojedynczego pliku, a nie całą gałąź/tag. Aby śledzić to, co zostało scalone, subversion umieści właściwość mergeinfo na najbardziej ogólnym węźle, ale najwyraźniej nie jest wystarczająco inteligentny w jej wybieraniu. Możesz rozwiązać ten problem, ręcznie edytując mergeinfo. Po prostu usuń właściwość ze wszystkich węzłów poniżej linii głównej i upewnij się, że gałąź ma wszystkie scalone wersje w jej mergeinfo. Oczywiście oznacza to, że musisz się upewnić, że zmiany zostały faktycznie scalone.

W sumie dość mylące, ale dobrą wiadomością jest to, że svn devs w rzeczywistości są pracują nad tym, aby wszystko stało się bardziej płynne.