W środowisku, w którym pracuje wielu programistów, komentowanie kodu jest wręcz wymogiem. Ale jak wiadomo wielu twórców oprogramowania unika dodawania komentarzy, a tym bardziej komentowania commitów w systemie kontroli wersji. Ale jest na to sposób by wymusić dodawanie komentarzy do każdego commita.

Na serwerze gdzie jest usługa SVN w katalogu danego repozytorium znajduje się katalog hooks. Znajdziemy tam pliki *.tmpl o nazwach, które sugerują swoje działanie. Są to pliki szablonowe, z których możemy przygotować gotowe skrypty.

Takim skryptem będzie pre-commit. Jak sama nazwa wskazuje, wykona się on przed każdym poleceniem COMMIT, sprawdzi czy programista dodał komentarz i jeśli nie to zwrócić błąd w stronę klienta.

Na samym początku musimy stworzyć taki skrypt. Posłuży nam do tego szablon pre-commit.tmpl.

cp /var/svn/repozytorium/hooks/pre-commit.tmpl /var/svn/repozytorium/hooks/pre-commit
chmod +x /var/svn/repozytorium/hooks/pre-commit

W skopiowanym pliku powinniśmy zakomentować linię dodając # na jej początku:

#commit-access-control.pl "$REPOS" "$TXN" commit-access-control.cfg || exit 1

Jeżeli chcemy, aby został wysłany do użytkownika odpowiedni komunikat możemy cały skrypt zastąpić poniższym kodem:

REPOS="$1"
TXN="$2"

# Make sure that the log message contains some text.
SVNLOOK=/usr/local/bin/svnlook

LOGMSG=`$SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c`
if [ "$LOGMSG" -lt 1 ]; then
        echo -e "Dodaj komentarz do swojego commita!" 1>&2
        exit 1
fi

# Check that the author of this commit has the rights to perform
# the commit on the files and directories being modified.
#commit-access-control.pl "$REPOS" "$TXN" commit-access-control.cfg || exit 1

# All checks passed, so allow the commit.
exit 0

Jeżeli wszystko dobrze wykonaliśmy, próba dodania commita bez komentarza zakończy się błędem:

Zatwierdzenie nie powiodło się (szczegóły poniżej):
svn: Commit blocked by pre-commit hook (exit code 1) with output:
Dodaj komentarz do swojego commita!

Natomiast jeżeli zobaczymy błąd Error output could not be translated from the native locale to UTF-8, należy sprawdzić czy w pliku pre-commit nie dodaliśmy jakiś znaków specjalnych, które powodują problem.

Poprzedni artykułMagazyn BSD numer 08/2011
Następny artykułLinus Torvalds nie lubi GNOME 3 – przechodzi na Xfce

12 KOMENTARZE

  1. Dzięki! Właśnie tego potrzebowałem. Działa idealnie i faktycznie wkurza programistów ;-) Ale przynajmniej mam porządek w kodzie.

  2. U mnie w pracy zastosowano takie rozwiązanie. Bardzo szybko zaczęły pojawiać się komentarze typu: "dfajsdlkfjasodif". Ale to już nie problem systemu kontroli wersji, tylko odpowiedzialności programistów za swój kod.

    • Dokładnie. Ale wtedy wiadomo kto w taki sposób komentuje zmiany i można z takim deweloperem porozmawiać na osobności. Komentowanie commitów jaki i samego kodu to nie jest głupie widzimisie jakiegoś PMa tylko sensowne podejście do programowania w zespole.

      Ciekaw jestem kiedy ja zacznę widywać podobne wpisy ;-)

    • Faszystowskie jest brak komentowania zmian. U mnie w firmie podstawą zarządzania projektami jest Redmine, więc oprócz wymuszania komentarzy programiści są zobligowani do podawania numeru tickea/requestu nad którym pracują. I nie ma zmiłuj… kwestia kultury pracy.

    • Oczywiście, że jest opierdziel… Za komentarz 'fix' do zadania o temacie np. 'Deploy new app version on staging server' nie ma zmiłuj ze strony PM'a. Gość za drugim razem nie da takiego komentarza. Jak już wspomniałem, wszystko zależy od kultury pracy firmy, gdyż nawet wymuszanie komentarzy za pomocą svn nie pomoże, gdy kultura pracy leży… Z resztą, nie jeden doświadoczony programista i administrator owych aplikacji wie, że komentarze są bezcenne, gdy pojawi się problem.

    • Wiele aplikacji umożliwia wybranie komentarzy z szablonu. Zawsze można przygotować gotowe komentarze na typowe commity dla takich leniuchów.

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj