Muszę przyznać, że nie używałem łatek, więc może to nie być właściwy przepływ pracy, ale spróbowałbym, gdybym był w takiej sytuacji, by zastosować łatę do zestawu zmian, na którym pierwotnie był oparty.
Innymi słowy, to brzmi jak masz następujący przypadek:
+-- you're here
|
v
1---2---3---4---5---6
\
\
X <-- patch was built to change 2 to X
Co bym zrobił, o ile znam changeset łatka została pierwotnie w oparciu o, byłoby zaktualizować z powrotem do tego changeset, zastosuj łatę, to doda kolejną głowę, a następnie połącz ją z czubkiem repozytorium.
Po tych działaniach, repozytorium powinno wyglądać następująco:
+-- you're here
|
v
1---2---3---4---5---6---8
\ /
\ /
7-------------/
^
|
+-- this is the changeset you committed after applying the patch
Teraz, na inny sposób.
Czy używanie łatki jest jedynym sposobem? Jednym z typowych sposobów używania Mercurial jest skonfigurowanie własnego repozytorium, widelca, zawierającego pierwotnie pełny klon centralnego repozytorium, ale masz dostęp do commitowania.
W ten sposób możesz zatwierdzić nowe zestawy zmian w swoim własnym klonie.
Jeśli centralne repozytorium ma nowe zestawy zmian dodane po sklonowaniu, w pewnym momencie wyciągniesz go z klonu i scalisz.
Następnie, gdy jesteś usatysfakcjonowany, wysyłasz prośbę o zwolnienie do opiekunów centralnego repozytorium, mówiąc im: "Hej, mam dla ciebie pewne zmiany, możesz wyciągnąć je z mojego klonu tutaj: http: // ... ".
W ten sposób naprawdę łatwo jest zapewnić wszystkim opiekunom, że wykonali dla nich ciężką pracę.
Oznaczałoby to, że masz dwa repozytoria tak:
central: 1--2
clone: 1--2
dodać swoją pracę:
central: 1--2
clone: 1--2--3
Dodają kilka Zestawienia zmian:
central: 1--2--3--4--5--6
clone: 1--2--3
Wtedy można wyciągnąć :
central: 1--2--3--4--5--6
clone: 1--2--4--5--6--7
\
\
3 <-- this is your changeset
Następnie połączyć:
central: 1--2--3--4--5--6
clone: 1--2--4--5--6--7--8
\ /
\ /
3--------/
Jeśli opiekunowie teraz wyciągnąć od ciebie dostać one dokładnie taką samą historię w swoim repozytorium.
Istnieje również pewne wsparcie dla rebase, co oznaczałoby, że nie musiałeś ciągnąć i scalać, ale opiekunowie wydaliby polecenie "pull with rebase", w efekcie przenosząc twój zestaw zmian z jego aktualnej pozycji do nowego pozycja w ich repozytorium, wyglądałoby to następująco:
central: 1--2--3--4--5--6---7
^
clone: 1--2--3 | relocated here
| |
+------------+
Działa to tylko wtedy, gdy nie ma konfliktów scalania. Metoda, w której możesz ciągnąć i łączyć, jest dla nich najlepsza, ponieważ wykonujesz całą ciężką pracę, muszą jedynie sprawdzić, czy kod jest tym, czego chcą.
Aby uzyskać więcej informacji na temat wideł, sprawdź wideo Tekpub na CodePlex i Mercurial, tutaj: , odszukaj około 21:15, aby rozpocząć rozwidlanie.
Należy zauważyć, że "widelec" jest w zasadzie zwykłym klonem, sposób w jaki rozwidlenie działa w CodePlex polega na tym, że automatyzuje on tworzenie klona na własnym koncie i wysyłanie oryginalnym opiekunom żądania ściągnięcia, ale jeśli tworzymy własne konto na Bitbucket lub CodePlex lub cokolwiek innego, opublikuj tam swojego klona i po prostu wyślij opiekunom e-mail z adresem URL twojego repozytorium, to wszystko, co do niego należy.
Jak o aktualizacji z powrotem do changeset łatka została zbudowana na, stosując ją, zobowiązując go, a następnie łącząc je z głowy? –
@Lasse dzięki za sugestię. Dam ci to i spróbuj złożyć raport. To może być warte opublikowania jako odpowiedzi, więc łatwiej jest przegłosować – greatwolf