2011-01-06 13 views
5

Po każdym zatwierdzeniu w "trunk", automatycznie uruchamiamy szereg testów przeciwko trunkingowi. Kiedy te testy przejdą, chciałbym zautomatyzowanego scalania w gałąź zwaną "test-passed". Kiedy testy zakończą się niepowodzeniem, żadne połączenie nie powinno się zdarzyć, ale gdy problem zostanie rozwiązany w "bagażniku" przy następnym lub późniejszym zatwierdzeniu, wszystkie zmiany powinny zostać scalone.Jak automatycznie przechodzić w tryb łączenia, gdy przechodzą testy automatyczne?

Chodzi o to, aby mieć gałąź, która ma tę samą treść co trunk, ale jest to odrobinę bardziej przy zdrowych zmysłach niż "trunk", ponieważ minęły przynajmniej automatyczne testy.

Mam skrypt, który próbuje to zrobić ręcznie, ale jest to włamanie przy użyciu niestandardowych właściwości, które nie zawsze działają poprawnie - jak właśnie się dowiedziałem. Jak najlepiej zrobić, żeby Subversion to zrobił?

+0

Jak planujesz poradzić sobie z konfliktami scalającymi? – Steve

+1

Nie wydaje mi się, aby wystąpiły jakiekolwiek konflikty scalania: "test-zaliczony" ma zawsze tę samą treść co "trunk", z wyjątkiem sytuacji, gdy HEAD w "trunk" nie przechodzi testów, w takim przypadku ma taką samą zawartość jak "bagażnik" po ostatnim badaniu. –

Odpowiedz

5

uruchomić te polecenia w katalogu głównym kopii roboczej testy ominąć, gdy jesteś pewny, że nowy pnia rewizja <somerev> przeszedł testy:

svn update 
svn merge http://example.com/svn/myproject/trunk -r 0:<somerev> 
svn commit -m "merged trunk revisions up to <somerev> into tests-passed" 

Ilekroć użyć polecenia scalania, SVN zanotuje połączenie w usłudze svn:mergeinfo. Tak więc powyższe polecenie powinno automatycznie określić, które wersje z zakresu 0:<somerev> kwalifikują się do scalenia, wyłączając wszelkie scalenia, które zostały już wykonane.

Tak jak powiedziałeś w komentarzu, nie należy spodziewać się konfliktów. Czasami jednak widziałem nieoczekiwane konflikty podczas łączenia szeregu wersji SVN zawierających nazwy. Aby pozbyć się tych konfliktów, można użyć opcji --accept theirs-full za pomocą polecenia scalania, aby zawsze akceptować stan trunkingu.

+0

Ah, "automatycznie określ, które wersje są kwalifikowalne" jest fajne, nie wiedziałem o tym. Myślałem, że muszę jakoś to przetworzyć, co brzmiało brzydko. Jak sugerujesz, że znajduję ? Próbowałem "trunk svnversion", czy musi to być +1? –

+0

@Johannes: nie musi być +1. Na przykład, jeśli najnowsza pomyślna kompilacja jest dla wersji 100, możesz scalić '-r 0: 100'. –

0

Wyobrażam sobie, używając tego zestawu testów, aby to zrobić.

Z mojego doświadczenia wynika, że ​​uruchomiłbym skrypt ANT, aby przetestować mój kod, i mam ostateczne warunkowe wykonanie gałęzi, jeśli testy zakończyły się pomyślnie.

+0

Rzeczywiście przeprowadzamy testy z mrówką, a my mamy stan końcowy dokładnie tak, jak mówisz. Pytanie brzmi: jak sprawić, aby svn przeprowadził odpowiednie scalanie w oparciu o ten warunek? –

+0

Czy podążacie za Name_spacing z każdym nowym kodem. (wersja kodu) może pomóc w tej sytuacji. – NaV

+0

Ahem? Nie mam pojęcia, o czym mówisz ... –

1

Do tego celu można użyć narzędzia Continuous Integration Tool. Jeden dość popularne: Hudson

http://hudson-ci.org/

Można skrypt, który rodzaj zachowania nie.

+0

Ponownie, moje pytanie dotyczy części svn, a nie części planowania lub skryptowania. Chyba że Hudson ma trochę magii svn, o której nie wiem?(Nasza konfiguracja tutaj używa Hudsona do uruchamiania kompilacji i testów w odpowiedzi na checkiny w "trunk"). –

Powiązane problemy