Wiele jednoczesnych systemów kontroli wersji?

Question

Jestem względnie nowy w zakresie kontroli wersji i do tej pory mam jedynie doświadczenie w pracy z Subversion przy użyciu TortoiseSVN/VisualSVN. Czytałem o innych rodzajach VCS (git, mercurial, itp.) I rozważam ich wypróbowanie - jednak wiele argumentów za lub przeciw konkretnemu VCS wydaje się w dużej mierze sprowadzać do subiektywnych preferencji, więc " Pewnie skończy się na tym, żeby każdemu rzucić okiem.

Zastanawiając się nad tym, zastanawiałem się, czy teoretycznie możliwe byłoby użycie wielu VCS w jednym kodzie. Które (jeśli w ogóle) kombinacje VCS może to być możliwe? A jeśli to możliwe, ile logistycznego koszmaru będzie próbował żonglować odpowiednimi listami wykluczeń?

Jednym z możliwych argumentów może być zapasowa redundancja. Kilku dostawców VCS (Beanstalk, Github, Bitbucket) oferuje jedno bezpłatne repozytorium, więc możesz mieć to samo bezpłatne wycofanie repo w kilku różnych miejscach.

Answer 1

Oczywiście, jest to możliwe, nawet powszechne w niektórych przypadkach. Na przykład: git i svn są naturalną parą. Standardowy przypadek użycia to organizacja, która musi mieć starsze centralne repozytorium Subversion z różnych powodów, ale w której programiści chcą używać Git do zwiększenia produktywności, jakie zapewnia.

Wpisz git-svn. Teraz programiści pchają i ciągną od swoich lokalnych repozytoriów Git do centralnego repozytorium Subversion, ale wciąż otrzymują całą fajną moc Gita. Proces ten jest całkowicie i całkowicie przejrzysty dla repozytorium Subversion, które po prostu widzi zmiany, które zostają do niego przeniesione.

Answer 2

To zwykle trudne (ale nie niemożliwe), aby obsłużyć wiele VCS na jednym kodzie. Jednak potencjalnie napotkasz problemy z usunięciem plików ... Czasem jeden VC nie zdaje sobie sprawy, że plik został usunięty.

Jednak nie polecam tego. Większość VC używa plików w bazie kodu do śledzenia zmian. Posiadanie wielu systemów VC będzie zanieczyszczać twój system plików dużą ilością plików, które mogą powodować problemy w innych VC.

Answer 3

wiem, że to nie jest całkiem za pomocą wielokrotnego VCSs, ale jest to możliwe dla niektórych VCSs mieć różnych interfejsów. Git, na przykład, może mieć przedni koniec SVN, dzięki czemu klienci SVN mogą używać repozytorium Git (i nie będą mądrzejsi, że to Git). Myślę, że dostępne są również inne interfejsy.

Answer 4

Mercurial (z hgsubversion), git (z git-svn) i bzr (bzr-svn) mają opcję synchronizacji z repozytorium svn.

Tak więc jest to już możliwe (zakładając, że rozszerzenia działają wystarczająco dobrze), aby współdziałać z repozytorium svn z różnymi SCM.

Answer 5

Z pewnością można to zrobić. Używam git-svn do aktualizowania lokalnego repozytorium git i zatwierdzania korporacyjnego repozytorium svn. Przy każdym narzędziu VCS, które zdecydujesz się użyć, najprawdopodobniej napotkasz problem podczas aktualizowania lokalnego repozytorium zmianami ze zdalnego repozytorium.

Jeśli korzystasz z bazaru w lokalnym repozytorium, the most problematic thing jest wtedy, gdy twoje lokalne repozytorium bazarowe jest rozbieżne i chcesz zatwierdzić do zdalnego repozytorium. Czasami musisz zrobić "push overwrite", aby go rozwiązać.

Nie odczuwam tego "problemu z rozłożonymi repozytoriami", gdy używam git-svn do aktualizacji lokalnego repozytorium git ze zmianami ze zdalnego repozytorium svn.Ale czasami, gdy robię "git svn rebase", będzie to powodować konflikty, a jeśli nie zrobisz procedury, aby rozwiązać to prawo, możesz spędzić dużo czasu. Ponieważ spotkałem się z tym w kółko, mam documented it i nie uważam tego teraz za wielką.

Answer 6

Moja pierwsza odpowiedź, kiedy przeczytałem twoje pytanie, brzmiała: "Oczywiście, technicznie możliwe, ale naprawdę zły pomysł".

Cofnę się trochę po zobaczeniu innych komentarzy. W porządku, każdy użytkownik może mieć lokalne repozytorium oddzielne od centralnego repozytorium, i używać go do utrzymania punktów kontrolnych podczas pracy. W takim przypadku mogą być całkowicie oddzielnymi VCS i nie będzie to miało znaczenia.

Ale jeśli myślisz o dwóch różnych VCSs jednocześnie trzymając centralne repozytorium, to techincally możliwe, ale naprawdę bardzo zły pomysł. Cały sens VCS polega na tym, że przechowujesz historię wszystkich zmian dokonanych w plikach, możesz zobaczyć, jakie zmiany zostały wprowadzone, kiedy i - jeśli użytkownicy zawierają w połowie przyzwoite komentarze dotyczące zatwierdzeń - dlaczego. Jeśli klient, który ma wersję z 19 czerwca 2007 r., Ma problem, możesz pobrać kod dokładnie tak, jak istniał w dniu 19 czerwca 2007 r., Więc debugujesz kod, który faktycznie uruchamia użytkownik. Jeśli odkryjesz, że ostatnia zmiana była dużym błędem, możesz wycofać. Itp itd

Ale jeśli masz dwa repozytoria ... Czy zamierzasz zrobić każdy popełnić identycznie na obu repozytoriów? Przynajmniej to dużo dodatkowej pracy. W najgorszym razie prędzej czy później ktoś popełni błąd, zapomni o zobowiązaniu się do popełnienia błędu lub nie popełni tego do następnego dnia po tym, jak ktoś inny dokonał interwencji, a repozytoria nie będą tak naprawdę identyczne. Czy zamierzasz przemianować, czasami sprawdzając z A, a czasami z B? Ale wtedy nikt nigdy nie będzie wiedział, co jest w jednym.

mogłem zobaczyć przy użyciu dwóch różnych VCSs na kilka dni lub kilka tygodni, żeby je wypróbować i zobaczyć, jak one działają, poczuć, dla którego chcesz lepiej. Ale nawet na tym nie zrobiłbym tego jako mojego systemu produkcyjnego. Miałem prawdziwą produkcję VCS, a potem drugą stronę, z którą gramy, ale nikt nie traktuje tego jako autorytatywny.