2009-12-07 23 views
5

Czy można użyć komunikatu zatwierdzenia w hakowaniu przed zatwierdzeniem w CVS? Serwer CVS działa zdalnie i uzyskuję do niego dostęp za pomocą pserver.Użyj komunikatu zatwierdzenia w haku poprzedzającym commit CVS

Idealnie, chcę zezwolić na zatwierdzenie, jeśli pliki przechodzą filtr lub wiadomość zatwierdzenia zawiera pewien tekst.

Nie mam wyboru, aby użyć innego systemu wersjonowania.

Odpowiedz

3

Oto kilka przydatnych tutoriali, aby dowiedzieć się więcej:

http://durak.org/sean/pubs/software/cvsbook/The-commitinfo-And-loginfo-And-rcsinfo-Files.html
http://durak.org/sean/pubs/software/cvsbook/The-verifymsg-And-rcsinfo-Files.html#The-verifymsg-And-rcsinfo-Files

Nie możesz robić, co chcesz za pomocą jednego haka, ale można korzystać z dwóch haków, commitinfo pozwolisz sprawdź same pliki, a verifymsg pozwoli ci zweryfikować wiadomość. Oba mogą być użyte do anulowania zatwierdzenia (programy muszą wyjść ze statusem 1). W przypadku, gdy nie byłeś tego świadomy, checkoutlist, commitinfo i "verifyymsg" można znaleźć w katalogu CVSROOT twojego repozytorium. Polecam umieszczenie wszystkich skryptów, które piszesz, jako hooków w tym katalogu, ale nie ma to znaczenia, gdy dojdziesz do określenia pełnej ścieżki. Ponadto, Perl nie jest konieczne lub wymagane, tylko proste dla mnie napisać kilka (głupie) Przykłady w:

checkoutlist

# these files will be automatically checked out for you 
acceptable 

verifymsg

# specifies which file to run as hook, %l is filename of log message 
# bar$  /path/to/repo/CVSROOT/verify_ends_in_bar %l 
DEFAULT /path/to/repo/CVSROOT/acceptable %l %s 

dopuszczalne

#/usr/bin/perl -w 

use strict; 
use warnings; 

# this would be simpler if cvs passed sane arguments 
my ($logfile, $dir, @files) = @ARGV; 
my $grep = `grep -i 'accept liability' $logfile`; 
exit 0 if $grep; 

my $found = 0; 
foreach my $file (@files) { 
    my $path = join '/', $dir, $file; 
    die "Can't find file $path" if ! -e $path; 
    my $grep = `grep -i 'evidence of any deliberation' $path`; 
    $found++ if $grep; 
} 
die "You must accept liability or show evidence of deliberation" if $found < @files; 

Zastrzeżenie emptora: Napisałem większość tego z mojej głowy bez żadnych testów, więc nie mogę zagwarantować, że to działa, ale powinno ci to przynajmniej przybliżyć.

Edit ponownie, zdałem sobie sprawę, że był pierwotnie źle i można przejść zarówno logfile i zaangażowanych nazwy plików na verifymsg czyni odpowiedź trochę prostsze.

+0

W jakiej wersji CVS próbowałeś? W mojej wersji, gdy określę% s w pliku 'verifyymsg', nie otrzymam plików zatwierdzonych, nadal otrzymuję tylko plik dziennika. – dreamlax

+0

@dreamlax Nigdy nie miałem potrzeby używać 'verifyymsg', tak jak ty, użyłem tylko' loginfo' i 'commitinfo' ale pomyślałem, że znalazłem kilka przykładów online, które pokazały' verifyymsg' akceptującą zarówno log plik i% s. Jeśli to nie zadziała, być może będziesz musiał powrócić do jakiejś komunikacji między skryptem 'commitinfo' a skryptem' verifyymsg'. –

+0

@dreamlax Czy mógłbyś spełnić oba kryteria? Wtedy mogłaby działać wcześniejsza wersja mojej odpowiedzi, która użyłaby commitinfo i verifyymsg. Sądzę, że zależy to od tego, czy chodziło o logiczne **, czy **, lub bardziej typowo angielskie ** lub **. –

1

Możesz użyć pliku verifymsg w katalogu CVSROOT. Możesz go skonfigurować, aby wywoływał skrypt, który może zweryfikować zawartość komentarza checkin. Możesz odrzucić zatwierdzenie, zwracając wartość niezerową.

Domyślny plik verifyymsg zawiera więcej szczegółów.

+0

Chcę odrzucić zatwierdzenie, jeśli zawieszanie wstępnego zatwierdzenia nie powiedzie się * i * komunikat dziennika nie * nie * zawiera "Akceptuję odpowiedzialność" lub cokolwiek innego. Hak przed zatwierdzeniem zapewnia, że ​​pliki są prawidłowe, ale w przypadku, gdy konieczne jest zatwierdzenie plików, które łamią reguły, chcę się upewnić, że dziennik to wymienia. Chcę móc sprawdzić zatwierdzone pliki * i * zatwierdzone pliki przed zezwoleniem na zatwierdzenie. – dreamlax

+0

Problem polega na tym, że haczyk przed zatwierdzeniem wydaje się nie być w stanie uzyskać dostępu do komunikatu zatwierdzenia, aby upewnić się, że nieudana weryfikacja jest logowana jako celowa, a hak weryfikacyjny nie może uzyskać dostępu do zmienionych plików, aby sprawdzić, czy zmiany są zgodne z zasadami. – dreamlax

+0

Masz rację, weryfikator nie może uzyskać dostępu do plików, które zostały zatwierdzone. Będziesz musiał je wdrożyć osobno. Jeśli więc się nie uda, całe zatwierdzenie się nie powiedzie. Czy to robi, co chcesz? Również, aby wyjaśnić, o ile pamiętam, nie można uzyskać rzeczywistych plików w haczyku przed popełnieniem przestępstwa, po prostu podano ścieżki/nazwy. –

3

Moduł Perla wydaje się mieć eksperymentalną cechę, która pozwala na buforowanie wartości między wywołaniem różnych wyzwalaczy. Strona wyraźnie wspomina o przekazywaniu nazw plików z commitinfo do verifyymsg, więc może pomaga ci osiągnąć to, co chcesz.

+0

Dzięki za to. Poszedłbym na tę odpowiedź, z tym wyjątkiem, że jak pan stwierdził, jest to eksperymentalna i potrzebuję czegoś bardziej konkretnego. – dreamlax

0

Mam do czynienia z tym samym problemem. Do tej pory moim najlepszym rozwiązaniem było uzyskanie identyfikatora procesu nadrzędnego (getppid()) i użycie go w pliku tymczasowym, w którym mogę umieścić listę plików z commitinfo. Ten macierzysty identyfikator wydaje się być taki sam dla procesu verifyymsg (przynajmniej w systemie AIX). Powodzenia.