2012-01-19 7 views
9

Jestem w trakcie pisania skryptu aktualizacji, który ściąga najnowszą wersję wielu repozytoriów i odbudowuje projekty. Chciałem zrobić kompilacja warunkowa, więc próbowałemMercurial: sprawdź, czy ostatnie ciągnięcie/aktualizacja wprowadziło zmiany

hg pull -u && ant clean build 

i zmienność

hg pull; hg update && ant clean build 

Jednak ant build jest wywoływana zawsze, nawet wtedy, gdy nic się nie zmieniło. Wiem, że mogę użyć hg incoming, aby sprawdzić zmiany przed wykonaniem polecenia pull, ale wydaje mi się to marnotrawstwem.

Jak mogę sprawdzić nowe zmiany, bez konieczności kontaktowania się z serwerem dwa razy (raz na hg incoming, raz hg pull)?

UPDATE: To jest mój build skrypt teraz:

update() { 
    TIP=$(hg tip --template "{node"}) 
    hg pull -u 
    if test "$TIP" != $(hg tip --template "{node}"); then 
    ant clean build 
    fi 
} 

(cd repo1; update) 
(cd repo2; update) 

i dla ludzi, zastanawiając się, dlaczego robię czystą kompilację za każdym razem, istnieją dwa powody:

  1. repozytoriów zależą od siebie nawzajem, a gdy API w jednym z nich ulegnie zmianie, muszę wykonać pełną przebudowę, aby znaleźć miejsca, w których zmiany API przełamują kod
  2. Kompilator Java wstawia stałe, również z inne pliki klas. Teraz, kiedy zmienię stałą w klasie z powrotem na pole, które może się zmienić, wszystkie inne pliki klas używające tej stałej pozostają nietknięte przez kompilację, co może prowadzić do subtelnych błędów, których chcę uniknąć.
+1

Nie powinien być prawidłowy system budowy, czytaj: nie mrówka, być w stanie tworzyć przyrostowe kompilacje? – jmg

+0

mrówka może tworzyć przyrostowe kompilacje, ale chcę uniknąć subtelnych błędów, więc za każdym razem wykonuję czystą kompilację. –

+1

, więc w jaki sposób rozwijanie własnych przyrostowych buildów pomaga uniknąć subtelnych błędów? –

Odpowiedz

9

Nie należy po prostu uruchomić hg incoming dwukrotnie, ponieważ zostanie on faktycznie pobrać wszystkie Zestawienia zmian dwukrotnie wtedy. To dlatego, że nie można po prostu rzucić okiem na zdalne repozytorium bez uruchamiania pełnego hg pull.

Więc zapisać przychodzące Zestawienia zmian w wiązce i wyciągnąć z tym, że zamiast:

hg incoming --bundle incoming.hg && hg pull --update incoming.hg && echo "Go!" 

The hg incoming poleceń działa jako osłona dla następujących poleceń: the && jest zwarcie więc pierwsze polecenie, które zwracają niezerowy kod wyjścia spowoduje, że cała konstrukcja zakończy się niepowodzeniem wraz z kodem wyjścia. Oznacza to, że hg pull i wszystkie poniższe polecenia nie są w ogóle wykonywane, gdy hg incoming sygnalizuje, że nie ma nic do wyciągnięcia.

+2

Właściwie nie dzwonił dwa razy. Ale nie zdawałem sobie sprawy, że nadchodzące pliki pobierają pełny zestaw zmian, więc wykonywanie przychodzących i ciągnięcie powoduje ściąganie rzeczy dwa razy. –

+0

Dziwne, 'hg pull --update && echo" Go "' zawsze robi 'echo', ale' hg pull - aktualizuje incoming.hg && echo "Go" 'tylko po wprowadzeniu nowych zmian. Czy jest jakiś powód? –

+0

@AdamHouldsworth: Tak, przychodzące i ciągnące są naprawdę tym samym (przychodzące po prostu wyrzucają zestawy zmian). Dokumentacja nie jest bardzo jasna, więc nie można winić za myślenie, że taniej jest uruchomić przychodzące. –

3

Dołącz do @Adam

Cytaty z hg help incoming

Do zdalnego repozytorium, używając --bundle unika pobierania Zestawienia zmian dwukrotnie jeśli przychodzące następuje ciągnąć.

...

Zwraca 0 jeśli istnieją nadchodzące zmiany, 1 inaczej.