Krótko mówiąc, jakie są zalety git i mercurial w stosunku do subwersji?

Question

Czy ktoś może mi powiedzieć, jaki jest hype nad Git i Mercurial na Subversion?

Answer 1

Git i Mercurial to distributed, SVN nie jest.

Korzyść czy nie? Ty decydujesz ...

Answer 2

Porównania pro-git z różnymi systemami kontroli źródła można znaleźć pod adresem http://whygitisbetterthanx.com/. To co najbardziej podoba mi się w git to:

• Jest szybszy.
• Nie powiela kodu źródłowego, takiego jak SVN w podkatalogu .svn.
• Umożliwia zatwierdzanie offline, a następnie pchanie.

Answer 3

To nie tyle, że jedna strona jest "lepsza" od drugiej, to że GIT, Mercurial i inni pozwalają pracować w sposób inny niż Subversion czy CVS. Subversion i CVS oferują tylko scentralizowaną strukturę repozytorium, podczas gdy pozostałe są "rozproszone". Rozproszone podejście ułatwia współpracę ad hoc między programistami i może również wpływać na sposób zarządzania grupami zmian na własnym komputerze.

Która z metod najlepiej pasuje do Ciebie, zależy od Ciebie lub Twojej organizacji.

Answer 4

Dla mnie jedna ważna rzecz: SVN naprawdę nie obsługują tagi:

1. Tagi nie są symboliczne. Są to ścieżki w repo (kopie COW)
2. W SVN plik należy do tagu (ponieważ znacznik jest kopią pliku). W innych systemach i ludzkiej intuicji: tag należy do pliku. Jest to relacja przeciwna.
3. Dlatego trudno jest wymienić coś w stylu: "wszystkie znaczniki, które mają pliki". Informacje te nie są przechowywane bezpośrednio w repozytorium SVN.

Answer 5

Jeśli chodzi o Git, to myślę, że jest ich sporo, z których największym (moim zdaniem) jest zaawansowana obsługa rozgałęziania i łączenia Gita. Git sprawia, że ​​naprawdę łatwo jest rozgałęziać się, a jego zdolność do scalania zmian jest o wiele, dużo lepsza niż SVN. Narzędzia takie jak gitk również bardzo ułatwiają wizualizację relacji między gałęziami w repozytorium Git.

Istnieje wiele innych korzyści. Myślę, że Git ma lepsze narzędzia i lepszy zestaw narzędzi, a fakt, że nie wymaga centralnego repozytorium i "repozytorium", jest przyjemne, gdy sam pracujesz nad małymi projektami. Myślę, że łączenie i rozgałęzianie jest jednak największą korzyścią.

(dużo, że idzie do Mercurial, jak dobrze, chociaż nigdy nie lubiłem nacisk Mercurial na temat lokalnych klonów dla „rozgałęzienia.”; Wolę metodę git jest z zachowaniem wszystkich oddziałów w tym samym repo)

Answer 6

masz ten sam zakres „różnice” pomiędzy Git i SVN niż między Git and CleaCase
(see my post on those "VCS core concepts")

• SVN: liniowycentralne VCS, gdzie oddział i zmiennych są takie same (punkt w historii liniowy).
• git: DAG (Directed Acyclic Graph) rozmieszczone VCS, w którym każda droga wykresu jest gałąź, a każdy roboczy jest pełna składowania.

Ponieważ Git jest zawartość zorientowane, to znacznie bardziej efektywnie łączyć niż Subversion przez:

• znalezienie bardzo szybko w jej wykresie jakie muszą być połączone
• stosujące prawo plaster

Answer 7

Dla mnie svn działa dobrze. Dla 1 - 10 programistów, w oparciu o doświadczenie.

Jest oczywiste, gdzie "prawdziwa" wersja znajduje się w chmurze na nadmiarowym hoście (mam nadzieję, że jest to miejsce, które dba o twoje dane i czas pracy). Wygląda na to, że czytanie o GIT jest bardziej skomplikowane, większe i bardziej wydajne. Więc jeśli chcesz scentralizowanego przepływu pracy svn (zobacz stronę http://whygitisbetterthanx.com/) z mniejszą ilością sposobów robienia rzeczy itp., Użyj polecenia svn.

Użyłem CVS, dopóki nie było oczywiste, gdzie cała zabawa była. Sądzę, że za kilka lat, jeśli zmienię się ponownie, będzie to git? Ale tak naprawdę - jeśli spędzasz czas z systemem kontroli wersji w innym dniu niż dzień, w którym go skonfigurujesz, robisz coś złego.

Answer 8

Powiedz, że masz osobisty projekt, czy umieścisz go pod kontrolą wersji? (Mam nadzieję, że mówisz tak).

Jeśli tak, czy nie wolałbyś czegoś prostego? Git nie wymaga konfiguracji serwera ani niczego w tym stylu. Twój katalog roboczy jest twoim repozytorium.

Chcesz wypróbować nowy szalony pomysł? Po prostu oddziałuj i eksperymentuj z nim w tej gałęzi. Jeśli się powiedzie, wróć do głównej gałęzi i połącz się. Jeśli Twój pomysł nie zadziałał dobrze, po prostu wróć do głównej gałęzi i usuń gałąź crazy_idea.

Chcesz pracować nad crazy_idea, ale także normalnie rozwijać gałąź główną? Znowu, nie ma problemu, możesz przełączać się między gałęziami i scalać tylko crazy_idea po wystarczająco dojrzałym.

Nawet jeśli pracujesz w zespole, każdy programista (lub niewielka grupa programistów) może pracować nad pewnym pomysłem w oddziale eksperymentalnym przed połączeniem go z resztą kodu.

Przypuszczam, że to sprawia, że ​​otwarte źródło jest jeszcze łatwiejsze. Nie musisz udzielać uprawnień dostępu do nikogo. Jeśli ktoś wdrożył świetną funkcję, może poprosić o wyciągnięcie od niego. Jeśli podoba ci się to, co widzisz, możesz je scalić.

Oto niespodzianka: git jest znacznie prostszy niż svn.

Naprawdę. Zawsze słyszałem o kontroli wersji, ale nigdy tego nie robiłem. Czas, w którym próbowałem umieścić mój kod pod lokalnym serwerem svn, był koszmarem; Naprawdę tego nienawidziłem.

Teraz wszystko układam.

Answer 9

Konceptualnie organizują poprawki jako zestawy zmian, które umożliwiają bardzo łatwe rozgałęzienie/scalenie kodu. Scalanie gałęzi w SVN to bolesne doświadczenie.