Wykonując bez częściowego zatwierdzenia "Mercurial Way"

Question

sklep Subversion, rozważając przejście na Mercurial, próbując dowiedzieć się z wyprzedzeniem, jakie będą wszystkie skargi od deweloperów. Jest jeden dość powszechny przypadek użycia, którego nie rozumiem.

1. pracuję na jakiejś sporej funkcji i mam znaczną część kodu - lub ewentualnie kilka znaczących części kodu - w kawałkach na podłodze garażu, całkowicie nieprzydatne dla sprawdzenia, może nawet nie kompiluje.
2. Pojawia się pilna prośba o naprawę błędów. Poprawka jest dobra i lokalna i nie dotyka żadnego kodu, nad którym pracowałem.
3. Naprawiam poprawkę w mojej kopii roboczej.

Co teraz?

Przyjrzałem się "Mercurial cherry picking changes for commit" i "best practices in mercurial: branch vs. clone, and partial merges?", a wszystkie sugestie wydają się być rozszerzeniami o różnym stopniu złożoności, od Record i Shelve do Queues.

Fakt, że najwyraźniej nie ma w tym żadnej podstawowej funkcjonalności, sprawia, że ​​podejrzewam, że w pewnym sensie ten styl roboczy działa nieprawidłowo. Jak wyglądałoby podobne do Mercurial rozwiązanie tego przypadku użycia?

---

Edited by dodać: git, przeciwnie, wydaje się przeznaczony do tego obiegu: git add o naprawienie plików, nie git add cokolwiek innego (lub git reset HEAD cokolwiek mogło już dodane), git commit.

Answer 1

Wiele przydatnych funkcji dla Mercurial ma postać rozszerzeń - nie bój się ich używać.

Co do Twojego pytania, record zapewnia to, co nazywasz częściowym zatwierdzeniem (pozwala ci wybrać porcje zmian, które chcesz zatwierdzić). Z drugiej strony, shelve pozwala tymczasowo wykonać czystą kopię roboczą, zachowując zmiany lokalnie. Po zatwierdzeniu poprawki możesz anulować zmiany i kontynuować pracę.

Kanonicznym sposobem obejścia tego (tj. Użycie tylko rdzenia) byłoby prawdopodobnie zrobienie klonu (zauważ, że lokalne klony są tanie, ponieważ zamiast kopii tworzone są twarde linki).

Answer 2

Użytkownik sklonowałby repozytorium (tj. Utworzył gałąź o poprawkach błędów w warunkach SVN) i naprawił stamtąd.

Alternatywnie, jeśli naprawdę jest to szybkie rozwiązanie, możesz użyć opcji -I przy zatwierdzaniu, aby jawnie sprawdzać poszczególne pliki.

Answer 3

Jak każdy DVCS, rozgałęzienie jest twoim przyjacielem. Rozgałęzienie repozytorium na wiele sposobów jest chlebem i masłem tego systemu. Oto git model, które możesz rozważyć, przyjmując, że działa całkiem dobrze także z Mercurialem.

Answer 4

Oto jak bym sobie sprawę:

1. posiada oddział dev
2. posiadają oddziały fabularnych
3. posiada prywatnego oddziału
4. mieć stabilną gałąź.

W twoim scenariuszu często zgłaszałbym się do mojego oddziału poza oddziałem funkcji.

Po otrzymaniu żądania, byłoby hg up -r XYZ, gdzie XYZ jest numerem rev, że są uruchomione, a następnie rozgałęzienie nowej gałęzi funkcji poza tym (lub up branchname, cokolwiek).

Wykonaj pracę, a następnie połącz się ze stabilną gałęzią po przetestowaniu pracy.

Przełącz się z powrotem na moją pracę i połącz się z węzłem zatwierdzania gałęzi głównej, integrując w ten sposób dwa strumienie wysiłku.

Answer 5

Oprócz what Santa said o rozgałęzienia będąc znajomego ...

Małe granularity Zobowiązuje to twój przyjaciel. Zamiast dokonywania wielu zmian w kodzie w pojedynczym zatwierdzeniu, zmień każdy logicznie niezależny kod w swoim własnym zatwierdzeniu. Wtedy znacznie łatwiej będzie wybrać zmiany, aby scalić gałęzie.

Answer 6

Nie używaj Mercurial bez użycia Mq Extension (jest dostarczany w pakiecie w domyślnej instalacji). Oprócz rozwiązania konkretnego problemu, rozwiązuje on wiele innych ogólnych problemów i naprawdę powinien być domyślnym sposobem, w jaki pracujesz (szczególnie jeśli używasz IDE, który nie integruje się bezpośrednio z Hg, sprawiając, że gałęzie przełączania są w locie trudny sposób pracy).