Najlepszy system kontroli źródła dla utrzymania różnych wersji

Question

Musimy być w stanie jednocześnie utrzymywać zestaw różnych wersji naszego systemu. Zakładam, że najlepiej to zrobić przy użyciu rozgałęzień. Obecnie używamy TFS2008 do kontroli źródła, elementów pracy i kompilacji automatycznych.

Jakie jest najlepsze rozwiązanie kontroli wersji dla tego zadania? Nasza organizacja jest w trakcie łączenia z TFS2010. Czy TFS2010 zapewni nam funkcjonalność, której potrzebujemy, aby z łatwością zarządzać serią oddziałów w zależności od wersji systemu? Musimy być w stanie utrzymać każdą wersję odizolowaną od innych, abyśmy mogli przeprowadzić testowanie i wdrożenie dla każdej wersji.

Nasz zespół programistów składa się z 5 deweloperów .net i dwóch twórców Flash.

Wiele słyszałem o GIT. Czy powinniśmy rozważyć użycie GIT zamiast TFS do kontroli źródła? Czy można używać TFS2010 razem z GIT? Czy ktoś ma podobne ustawienia, które działają dobrze?

Wszelkie sugestie są mile widziane!

Dzięki,

Kjetil.

Answer 1

Głównym powodem należy rozważyć Git (lub Mercurial) jest:

• jego Distributed nature
• łatwość łączenia (konsekwencji, rzeczywiście, być rozprowadzane)
0.

Jeśli Twój zespół znajduje się w jednej lokacji, a proces rozwoju jest wystarczająco liniowy (prosty proces scalania), wystarczy scentralizowany VCS.

Stamtąd TFS2010 poczyniła pewne ciekawe ewolucje, szczególnie na jego branching model i jego inne funkcje zintegrowane w nim (hierarchii elementów roboczych, budować z „Gated check-in” i opiera się na zasadzie „Workflow Foundation”) sprawia, jest lepszym kandydatem niż narzędzie ograniczone do aspektu VCS.

Answer 2

TFS 2010 - ręce w dół. Nie dlatego, że jest to świetny system kontroli wersji, ale z powodu całej reszty robi to. GIT pozostawi cię otwartą, by wybrać śledzenie elementów pracy, ciągłą integrację ponownie. Utrzymanie liczby dostawców (technologie o niskiej jest podstawowym dla lepszego zarządzania.

Answer 3

Mercurial będzie również wykonać zadanie.

Oto doskonały tutorial na nim.

Answer 4

Obecnie istnieją głównie dwa typy systemów kontroli wersji (VCS), tak zwane rozproszone systemy VCS i centralne systemy repozytoriów.

Najpopularniejszy obecnie "rozproszony" VCS to git i mercurial. Najpopularniejsze systemy centralnego repozytorium to subversion i SourceSafe firmy Microsoft. Wprowadzanie http://hginit.com wyjaśnia przewagę "rozproszonego" VCS nad systemem centralnym.

Z rozproszonym VCS każdy programista ma swoje lokalne repozytorium. Zwykle używa się wspólnego centralnego repozytorium z oficjalną wersją. Ale to tylko organizacja repozytorium. "rozproszone" VCS mają przewagę nad czysto scentralizowanym VCS pod względem możliwości zarządzania łączeniem.

Answer 5

Subversion !!!

Lubię Subversion + TortiseSVN + VisualSVN

http://subversion.tigris.org/
http://tortoisesvn.tigris.org/
http://www.visualsvn.com/

Subversion i Tortise są bezpłatne !, i VisualSVN jest tylko 50 $ za licencję (ale nie trzeba używać Visual-SVN, to tylko integracja VS .... nie jest to konieczne, jeśli chodzi o mnie.)

Oto poradnik i przewodnik instalacji dla wszystkich trzech produktów.
http://www.west-wind.com/presentations/subversion/

i inny ...
http://www.dev102.com/2008/10/07/how-to-use-the-svn-client-and-start-working-with-your-subversion-version-control/

Answer 6

Wszystkie wymagania potrzebne są wliczone w TFS 2010. rozgałęzienia, a gałęzie prowadzenie izolowane.

TFS to więcej niż system kontroli wersji. Jest to również system kontroli pracy/błędów i ma narzędzia do zintegrowanej kompilacji. Jeśli potrzebujesz tego, a masz już licencję na TFS 2010, nie marnuj czasu na inne systemy.

OK, TFS nie jest rozprowadzany, ale tak naprawdę podczas pracy lubię TFS nie być rozpowszechniany. Jak tylko sprawdzę rzeczy (w moim osobistym oddziale), będą one na codziennej kopii zapasowej i będą dostępne dla innych. (Do mojego domu/hobby/rzeczy osobistych używam mercurial).

W przypadku wszystkich innych systemów dostępne są narzędzia, które umożliwiają budowanie i śledzenie błędów, więc nie ma problemu z innymi narzędziami, które nie są dostępne, wystarczy tylko wybrać te, które odpowiadają Twoim potrzebom.

Answer 7

Po prostu uwielbiam git i jest on zintegrowany z wieloma innymi aplikacjami, takimi jak Eclipse, Trac. kto musi zapłacić za VCS, gdy masz Git.

Fakt, że rozwój jądra Linux używa git, wiem, ponieważ Linus tak powiedział :), który nie jest małym projektem mówi sam za siebie.

Answer 8

Dobry system kontroli rewizji pomoże mi, gdy będę pracował w sposób rozproszony. Nie dlatego, że lubię być rozpraszany, ale dlatego, że wymagania dnia codziennego mają sposób na rozproszenie tego, jak się działa. Rozpraszanie jest zaostrzane, gdy grupa pracuje równolegle w przyzwoitym projekcie.

Osoba A pracuje nad funkcją 1. Osoba B pracuje nad funkcją 2. Osoba C pracuje nad poprawieniem zgłoszonych błędów w wydanej wersji.

Podczas gdy A wykonuje swoją pracę, obserwuje błąd w kodzie i naprawia go na miejscu, aby go nie przeoczyć i kontynuuje. Osoba C wykonuje 3 poprawki.

A, B i C mają czat i B czuje, że potrzebuje poprawek C wykonał od razu, jak również poprawkę A, ale nie funkcję A. C chce naprawić błąd A. A chce naprawić błędy w C. I tak dalej.

Boss postanawia chcemy wersję z funkcją 1, kolejna wersja z funkcją 2 i wersja z obu funkcji, a wersja z ani wydany i utrzymane.

Jak dobrze narzędzie wspiera Cię w tych działaniach? Na ile narzędzie przeszkadza w tych czynnościach?

Jestem naprawdę zadowolony z "darcs".

Próbowałem już wielu systemów kontroli wersji. Nie spotkałem nikogo lepszego.

Jest prosty, jest rygorystycznie poprawny.

Ponieważ jest rygorystyczny, jest niezawodny i przewidywalny. Ponieważ jest to proste, pomocne i nie przeszkadza.

Moim drugim wyborem byłby git.

Git jest całkiem niezły, ale nie tak rygorystyczny, wymusza na tobie zamówienie przy pewnych okazjach, gdy zamówienie nie ma znaczenia. Git jest lepiej znany, więc lepiej wznowić bullet.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Answer 9

Na podstawie mojego doświadczenia, jeśli szukasz DVCS, Git czy Mercurial (Hg) jest droga. Podejmowanie decyzji między Git i Hg jest jednak trudniejszym zadaniem.

Czy używasz głównie systemu Windows? Jeśli tak, to Hg jest prawdopodobnie twoim przyjacielem. W połączeniu z TortoiseHg jest to bardzo dobre, wszechstronne narzędzie, które można łatwo rozpocząć w porównaniu z Git. Jest nieco mniej skomplikowany, ale obsługuje większość rzeczy, z którymi Git może sobie poradzić, nawet jeśli nie są tak płynne.

Jeśli używasz Linuksa lub powłoki Uniksa, Git byłby moim wyborem. Osobiście używam Git w oknach, używając narzędzia powłoki git. (W Cygwin też działa dobrze, jeśli wolisz) Stwierdziłem, że Git radzi sobie z moimi projektami znacznie skuteczniej niż Mercurial. Jednakże, jeśli nie jesteś doświadczonym z linii poleceń, stwierdziłem, że TortoiseGit jest nieco bardziej skomplikowany (i niezgrabny), że TortoiseHg. Ale ponieważ znam basha, git jest zdecydowanie moją preferencją. Jest po prostu szybszy, szczuplejszy i bardziej wszechstronny niż Hg, w moim czasie z obojgiem. Jest to po prostu nieco bardziej skomplikowane, więc krzywa uczenia się jest wyższa i na początku możesz być podatny na błędy, tak jak ja przez krótki czas.

Więc moim zdaniem, prawdziwe pytania:

Okna (Hg) lub Unix (Git)

i

graficzny (TortoiseHg) lub wiersza poleceń (Git shell)