Układ repozytorium Mercurial dla wielu gałęzi

Question

Mam kilka quasi-powiązanych projektów, które chcę kontrolować wersji. W SVN bym je ustawić jak wiele katalogów w ramach jednego projektu

/scripts #updates in sync with project1 & project2 
/project1 #requires database 
/project2 #requires database 
/database 

Naturalnie inne układy SVN są możliwe dla tego przykładu zabawek, ale ten układ ma zalety:

• mogę kopiować pliki między oddziałami zachowując historię
• mogę sprawdzić tylko część projektów, np svn co repo/project2; svn co repo/database. Pozwala to zaoszczędzić znaczną ilość miejsca na przechowywanie &, jeśli projekt1 jest duży.
• Łatwe zarządzanie repozytorium, ponieważ dostęp użytkownika jest zdefiniowana raz dla wszystkich projektów

ten paradygmat nie mapuje dobrze Mercurial od you can't clone a single directory of a mercurial repo. Moje pytanie brzmi: jaki jest najczęstszy sposób przechowywania dużych, ściśle powiązanych projektów w środowisku rtęciowym?

Moje pomysły:

• wielu repozytoriów - traci historię plików, które przemieszczają się między projektami
• Forests - wydaje zablokowanych, i nie jestem pewien, jak to rozszerzenie jest stabilny
• nazwanych gałęzie z większości niezwiązane treści
• SubRepos - Niestety, używam Ubuntu 9.04, który wysyła tylko hg 1.1.2. W przeciwnym razie mogłoby to wyglądać na dobrą opcję:

Answer 1

Wiele repozytoriów, Lasy i SubRepos to wszystkie warianty tego samego pomysłu. Lasy i SubRepos właśnie ułatwiają zarządzanie projektami, które korzystają również z bardzo niedawnych wersji innych projektów, nie rozwiązują podstawowego problemu, który masz, czyli tracisz historię plików podczas przenoszenia ich między projektami.

Moim zdaniem, najlepiej jest umieścić wszystkie katalogi w tym samym repozytorium i czekać na Mercurial funkcji w celu umożliwienia realizacji transakcji podkatalogów. Funkcja podkatalogu jest tym, czym zajmuje się zespół Mercurial, ale nie jest to łatwe, dlatego nie zostało to jeszcze zrobione. Znam jednak wewnętrzne Mercurial i jest to zdecydowanie wykonalne, po prostu dużo pracy.

Drugim najlepszym rozwiązaniem, choć uważam, że naprawdę brzydki, jest nazwany gałęzie pomysł wspomniałeś. Nadal będziesz mieć bardzo dziwną operację scalania do wykonania, gdy tylko chcesz skopiować pliki między oddziałami.Będziesz wykonać następujące kroki:

1. Update do szefa oddziału, który chcesz skopiować plik do: hg update -C project1
2. seryjnej w branży chcesz skopiować plik z: HGMERGE=/bin/false hg merge -r project2
3. powrócić do głowy oddziału chcesz skopiować plik do: hg revert -a --no-backup -r project1
4. Przywróć konkretny plik, który chcesz skopiować z rewizji szef połączyła w branży: hg revert --no-backup -r project2 path/to/file/in/project2.txt
5. przenieść plik w jego miejsce w branży, który chcesz skopiować to do: hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
6. Mark scaleniu jako rozwiązany: hg resolve -am
7. I wreszcie popełnienia wynik: hg commit -m "A merge to copy project2.txt to project1."

Jak powiedziałem, bardzo brzydkie. I może dobrze działać tylko w hg 1.3, ponieważ wiem, że kilka ważnych błędów w interakcji odwrotnej, scalającej i rozstrzygającej zostało naprawione całkiem niedawno. (IMHO, podejrzewam, że Ubuntu jest celowo w tyle w wersjach systemów kontroli wersji innej niż bzr.)

Jak często naprawdę oczekuje się kopiowania plików pomiędzy projektami? Dlaczego tak się stało? Jesteś pewien, że utrata historii byłaby czymś złym?

Zrobiłem coś podobnego w Subversion dla kilku własnych projektów, ale moje doświadczenie jest takie, że moje początkowe przekonanie o tym, w którym projekcie naprawdę było coś, było zazwyczaj poprawne, a kiedy nie było zachowania historii, nie było ". To naprawdę wielka sprawa, ponieważ historia była tak naprawdę ważna tylko w oryginalnym projekcie, w którym plik był.