Dlaczego nie mogę edytować komunikatu zatwierdzenia SVN?

Używam SVN. Czasami coś mi brakuje, kiedy piszę komunikat zatwierdzenia. Ale po popełnieniu nie można go przywrócić, a nawet ja nie mogę edytować wiadomości. Dlaczego nie umieścili w nim funkcji edycji?

version-control svn

— Sanghyun Lee
źródło

Przypomina mi historię Dave.cpp na thedailtywtf

— Falcon

Wystarczy użyć git , pozwala łączyć zatwierdzenia, edytować wiadomości i robić, co tylko zechcesz w swojej historii.

— SK-logic

A jeśli nie możesz, użyj git-svni nikt nie będzie mądrzejszy.

— Matthew Scharley,

@Matthew: jak u licha git-svn umożliwia zmianę historii w repozytorium svn z wyłączoną funkcją edycji historii?

— gbjbaanb

@gbjbaanb: Nie zrobiłby tego, gdybyś już wypchnął się na serwer SVN. Ale jeśli tylko zatwierdziłeś się lokalnie, nadal możesz zmienić komunikat zatwierdzenia przed przekazaniem go do repozytorium na żywo.

— Matthew Scharley,

Odpowiedzi:

Zgodnie z często zadawanymi pytaniami dotyczącymi SVN można to zrobić, jeśli administrator repozytorium włączył tę funkcję lub jeśli masz lokalny dostęp administracyjny do repozytorium .

Jednak zrobienie tego jest prawdopodobnie złym pomysłem. W rzeczywistości zmieniasz historię. Jednym z punktów kontroli wersji jest prowadzenie historii i ścieżki audytu dla projektu. Zezwolenie na dowolne zmiany w historii pokonuje ślad audytu. Zamiast tego zalecałbym wykonywanie mniejszych zatwierdzeń, pisanie zwięzłych, ale jednoznacznych komunikatów zatwierdzania i ulepszanie osobistego przepływu pracy, aby zapobiec tym błędom.

— Thomas Owens
źródło

@Matthew Nawet w git zmienianie historii w dowolnym momencie jest, moim zdaniem, okropnym pomysłem. Historia ma służyć jako ścieżka audytu i nigdy nie powinna być zmieniana przez nikogo w dowolnym momencie z jakiegokolwiek powodu.

— Thomas Owens

Przygotuj więc ścieżkę audytu dla komunikatu zatwierdzenia, ponieważ zazwyczaj celem zmiany komunikatu zatwierdzenia jest ułatwienie śledzenia historii projektu.

— Peter Taylor,

Przypuśćmy, że odkrywam, że przesłanie, które wprowadziłem miesiąc temu, wprowadza w błąd, jest mylące i wręcz błędne . Czy nie powinienem być w stanie dodać notacji korygującej, która będzie widoczna dla każdego, kto zobaczy niepoprawny komunikat? (Zgadzam się, że pierwotna wiadomość powinna być łatwo dostępna w niezmodyfikowanej formie, a sama zmiana powinna być śledzona i oznaczana datą. Ale nie zgadzam się, że stanowi to „zmieniającą się historię”.)

— David Schwartz

Błędne informacje są niedopuszczalne, dlatego nie należy pozwalać ludziom na poprawianie lub wyjaśnianie tych informacji, ponieważ mogłoby to ukryć ich nadużycia. Łał. Po prostu łał.

— David Schwartz,

Naprawdę zaczynasz wyglądać jak parodia. „To musi być poprawne, dlatego nigdy nie może być poprawione”.

— David Schwartz,

Zasadniczo musisz mieć uprawnienia administratora (bezpośrednio lub pośrednio) do repozytorium, aby to zrobić. Możesz albo skonfigurować repozytorium, aby wszyscy użytkownicy mogli to zrobić, albo zmodyfikować komunikat dziennika bezpośrednio na serwerze.

Sprawdź często zadawane pytania dotyczące SVN tutaj.
Komunikaty dziennika są przechowywane w repozytorium jako właściwości dołączone do każdej wersji. Domyślnie właściwości komunikatu dziennika (svn: log) nie można edytować po zatwierdzeniu. Wynika to z faktu, że zmiany we właściwościach rewizji (w tym svn: log) powodują trwałe odrzucenie poprzedniej wartości właściwości, a Subversion próbuje zapobiec przypadkowemu wykonaniu tej czynności. Istnieje jednak kilka sposobów na przekonanie Subversion do zmiany właściwości wersji.

Pierwszym sposobem jest włączenie przez administratora repozytorium modyfikacji właściwości wersji. Odbywa się to poprzez utworzenie haka zwanego „przedpremierową zmianą” (więcej informacji na ten temat można znaleźć w tej sekcji książki Subversion). Hak „przed zmianą poprawki” ma dostęp do starej wiadomości dziennika przed jej zmianą, dzięki czemu może ją w jakiś sposób zachować (na przykład wysyłając wiadomość e-mail). Po włączeniu modyfikacji właściwości wersji można zmienić komunikat dziennika wersji, przekazując przełącznik --revprop do svn propedit lub svn, jak na przykład:
$svn propedit -r N --revprop svn:log URL 
$svn propset -r N --revprop svn:log "new log message" URL 
gdzie N to numer wersji, którego komunikat w dzienniku chcesz zmienić, a URL to lokalizacja repozytorium. Jeśli uruchomisz to polecenie z kopii roboczej, możesz pominąć adres URL.

Drugim sposobem zmiany komunikatu w dzienniku jest użycie svnadmin setlog. Należy to zrobić, odwołując się do lokalizacji repozytorium w systemie plików. Za pomocą tego polecenia nie można modyfikować zdalnego repozytorium.
$ svnadmin setlog REPOS_PATH -r N FILE
gdzie REPOS_PATH jest lokalizacją repozytorium, N jest numerem rewizji, którego komunikat dziennika chcesz zmienić, a PLIK to plik zawierający nowy komunikat dziennika. Jeśli haczyk „przed zmianą poprawki” nie jest na swoim miejscu (lub z jakiegoś powodu chcesz ominąć skrypt przechwytujący), możesz również użyć opcji --bypass-hooks. Jeśli jednak zdecydujesz się skorzystać z tej opcji, bądź bardzo ostrożny. Być może omijasz takie rzeczy, jak powiadomienia e-mail o zmianie lub systemy kopii zapasowych, które śledzą właściwości wersji.

Odpowiedź Kamila Kisiela w odpowiedzi na podobne pytanie dotyczące przepełnienia stosu .

— Abimaran Kugathasan
źródło

Kiedy kopiujesz wklej odpowiedź z stackoverflow, powinieneś przynajmniej oznaczyć ją jako cytat i wyrazić uznanie dla OP (w tym przypadku Kamil Kisiel). Link do oryginału: stackoverflow.com/questions/304383/... Edytuj swoją odpowiedź lub zamierzam cię głosować.

— Falcon

Ponieważ jest to scentralizowany system kontroli wersji - od razu po zatwierdzeniu zmiany (a komunikat zatwierdzenia jest umownie związany z zatwierdzeniem), każdy, kto ma dostęp do odczytu do repozytorium, może zobaczyć te informacje. Zmiana informacji po ich rozpowszechnieniu jest złym pomysłem , ponieważ ludzie mają inne zdanie na temat „rzeczywistości”.

Rozproszone systemy kontroli wersji, takie jak Git, łagodzą ten problem, zapewniając, że udostępnianie informacji innym jest niepodzielne i bez żadnych dodatkowych informacji, takich jak komunikaty zatwierdzania. Ale ta sama zasada obowiązuje tutaj: zniechęcasz się do zmieniania lokalnie rzeczy, które już udostępniłeś innym.

— l0b0
źródło

Mogliby zezwolić na wiele wersji komunikatu zatwierdzenia ...

— Alex Feinman

@ l0b0 czy obiektywnie nie jest gorsze rozpowszechnianie informacji, które są fałszywe, wprowadzające w błąd lub podatne na wyrządzanie szkód? Prowadzenie dokumentacji nie wymaga zapisywania złych danych.

— user179700

@ user179700: Masz rację. We wszystkich VCSach jest zasadniczo błędne założenie projektowe: zatwierdzenie ma jeden komunikat zatwierdzenia, który jest niezmienny. Jak mówi Alex, powinniśmy „zezwolić na wiele wersji komunikatu zatwierdzenia”.

— l0b0

@ l0b0 Uważam to pytanie za interesujące, tym bardziej je rozważam. Moja pierwsza reakcja była następująca: po prostu pisz ostrożniej. Obecna praktyka wydaje się hamować ten proces. Też zastanawiam się, czy jakieś inne systemy stosują bardziej solidną praktykę. Czas na kolejne pytanie. +1

— użytkownik179700

@ user179700: Obecnie mam nadzieję napisać skrypt, który pozwoli ci zmienić komunikat zatwierdzenia, ale tylko poprzez dodanie (oznaczonego czasem) dodatkowego łańcucha. Pozwala to poprawić błędy przy jednoczesnym zachowaniu ścieżki audytu.

— Tynam