Słabe używanie SVN - czy Mercurial jest odpowiedzią?

W pracy używamy SVN, ale tylko z nazwy. Nie rozgałęziamy się ani nie łączymy. Przechowujemy dwie kopie repozytorium, jedną służącą jako gałąź „znacznika”, która jest kopiowana podczas wdrażania i przechowywana w celu naprawy błędów oraz natychmiastowe funkcje typu „to musi działać jak najszybciej”. Musimy pamiętać o skopiowaniu zmian dokonanych w jednej kopii do drugiej kopii („pnia”). Mamy kilkanaście projektów w jednym folderze w repozytorium, zamiast ich podziału. Krótko mówiąc, jedyną rzeczą, której używamy SVN, jest możliwość zatwierdzenia. Cała reszta odbywa się ręcznie.

Oceniałem Mercurial; W przeszłości korzystałem z Git (jako jedyny w zespole korzystałem z DVCS) i szybko odbieram Mercurial. Zastanawiam się nad wprowadzeniem Mercurialu dla reszty zespołu jako „lepszym sposobem” robienia rzeczy, ponieważ rozgałęzianie jest bardzo proste, łączenie jest o wiele łatwiejsze, a my możemy lokalnie przypisywać rzeczy do naszych serc i popychać je tylko do centrali rozgałęzić się, kiedy będą gotowe. Dostalibyśmy wszystkie zalety SVN (i tak teraz nie otrzymujemy wielu korzyści, ponieważ nikt tak naprawdę nie rozumie SVN), a ponadto w przypadku nowych funkcji nie musimy mieć pływających ton niewersjonowanych plików, więc jeśli musimy wycofać mamy przerąbane. Przepływ pracy wydaje się nieco prostszy - musimy tylko pamiętać, że „Commit” jest lokalny, a „Push” jest jak zatwierdzenie SVN,

Czy to dobre podejście? Należy pamiętać, że zespół jest bardzo elastyczny i dostosuje się do wszystkiego, co poprawi jakość naszej pracy i ułatwi nam robienie rzeczy - CIO zapytał mnie nawet, kiedy wspomniałem, że nie wykorzystujemy SVN do jego potencjału ” jest coś lepszego, czego możemy użyć? ” więc on też jest na pokładzie.

Tak.

Jeśli w swoim OP zamienisz „SVN” na „Perforce”, masz prawie taką sytuację, w jakiej się znalazłem, kiedy zaczynałem swoją obecną pracę, nawet w przypadku ręcznego kopiowania zmian. Dwa lata później jesteśmy w Mercurial i wszyscy zgadzają się, że to wielka zmiana.

Mamy możliwość rozgałęziania się i łączenia według przypadków wsparcia , co jest niewiarygodnie przydatne dla kontroli jakości, a także możliwość tworzenia dowolnej liczby odrzucanych oddziałów i repozytoriów, kiedy tylko uznamy to za stosowne, które możemy następnie zbudować i zweryfikować na naszym serwerze CI, a następnie wdrożyć do środowiska testowego w chmurze i sprawdź funkcjonalność. Przyniosło to ogromną korzyść, jeśli chodzi o spokój ducha, ponieważ podczas wdrażania na żywo jesteśmy prawie w 100% pewni, że zadziała (bez problemów związanych ze środowiskiem / DB, które oczywiście nie wchodzą w zakres VCS).

Zasadniczo to, co zyskaliśmy z przejścia na rtęć, to oddychanie przestrzenią. Nie musimy już martwić się kosztami oddziału ani przerażającymi sesjami łączenia, które nieuchronnie miały miejsce, wszystko jest o wiele łatwiejsze. Używamy również FogBugz dość mocno, więc powiązanie z Kiln (ich gospodarzem rtęci) jest naprawdę pomocne.

Komentarz na temat strony hginit również jest na miejscu, jako zarys przepływu pracy kontroli wersji, który faktycznie działa (zakładając, że dostosujesz go do konkretnego przepływu pracy w Twojej firmie).

Jedyną możliwą wadą ruchomych kontrolek wersji jest to, że będziesz potrzebować kogoś, kto naprawdę jest siłą napędową zmiany, który chętnie przeczyta temat i naprawdę wykorzysta narzędzia w najlepszym możliwym zakresie, co wydaje się, że chcesz robić.

Nie zgadzam się z komentarzami na temat wielkości zespołu i podziału zespołu odnoszącymi się do tego, czy użyć DCVS. Naprawdę chodzi o dystrybucję KODU. Jeśli równolegle dzieje się wiele cykli programistycznych, albo obsługuj skrzynki w starszym systemie, albo kilka funkcji, a nawet nowe systemy (które to robisz), skorzystasz z DVCS.

Inne narzędzie prawdopodobnie nie rozwiąże twojego problemu, powiedziałbym, że powinieneś przeczytać ten artykuł, uważam to za najbardziej pomocne:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Myślę, że główny punkt tego artykułu został tutaj podsumowany, ale proszę go przeczytać:

W końcu: nie naprawdę o narzędziach

Przez cały czas pracy i integracji różnych systemów kontroli źródła doszedłem do jednego wniosku: to nie jest narzędzie, tylko sposób korzystania z niego. To okropnie zhackowane stwierdzenie, ale wydaje się tutaj szczególnie prawdziwe. W przypadku prawidłowego zarządzania zmianami w kodzie źródłowym - etykietowania kompilacji, rozgałęziania przez wyjątki itp. - nawet najsłabszy system kontroli źródła (* kaszel * SourceSafe * kaszel *) znacznie przewyższy konfigurację Mercurial z szeregiem przypadkowych zobowiązań i popycha.

Nie. Technologia rzadko rozwiązuje tego rodzaju problem.

Mercurial jest bardziej złożony niż Subversion (tak, rozgałęzianie i scalanie jest lepsze i być może łatwiejsze, ale model Subversion jest znacznie prostszy niż model Mercurial). Jeśli używasz Subversion w taki braindeadowy sposób, możesz skończyć z Mercurialem:

• a) Odpowiednio lub lepiej
• b) Niewystarczająco, ale lepiej niż twoje obecne korzystanie z Subversion
• c) Tak nieodpowiednio jak teraz
• d) Gorzej niż teraz

c) id) brzmią jak najbardziej prawdopodobne wyniki. Napisz, dlaczego uważasz, że skończysz w a) lub b).

Nie mogę rozmawiać o tym, jak działają duże zespoły, ale dla małych zespołów wiele z tych dużych problemów SVN nie jest tak naprawdę problemami SVN ... Są to problemy programistyczne. Jeśli nie postępujesz zgodnie ze współczesnymi standardami programistycznymi (co najważniejsze, robisz ciągłą integrację), wersjonowanie zamienia się w dokładnie opisywany bałagan, który opisujesz ... Przed przejściem do nowego systemu upewnij się, że wykonałeś prawdziwą analizę pierwotnej przyczyny problemu ...

Nie. Narzędzia nie zastępują metodologii.

Jeśli nie używasz Subversion jako SCM , nie możesz również używać Mercurial (i najprawdopodobniej tak się stanie)

SVN może robić, co trzeba, i nie trzeba zmieniać koni w połowie strumienia, aby uzyskać wątpliwą spłatę.

Cokolwiek zrobisz, będziesz musiał przezwyciężyć problem zaufania. Ktoś musi być w stanie przekonać wszystkich do zmiany pracy. Nie jest to łatwe nawet w najlepszych okolicznościach, nawet jeśli masz logikę i fakty po swojej stronie. Jest to jedna z najtrudniejszych rzeczy do zrobienia w organizacji. Jeśli go spartaczysz lub stanie się trudny, stracisz zaufanie i bardzo trudno będzie odzyskać to zaufanie.

Wiem, że ludzie próbowali z powodzeniem kilku rzeczy. Być może jeden z nich będzie działał dla Twojego zespołu:

1. Sprowadzić „trenera”, który zapewni zespołowi szereg warsztatów. Prawdopodobnie będzie to osoba zewnętrzna (jak na ironię, wielu zespołom często łatwiej jest zaufać osobie z zewnątrz niż komuś w zespole). Musi to być ktoś, kto zna jej umiejętności na wylot i potrafi skutecznie uczyć tych umiejętności ludzi na wszystkich poziomach zrozumienia i opracować pragmatyczny plan wprowadzenia nowego VCS (*) do pracy zespołu.

2. Rozpocznij projekt „skunk-works”, aby przetestować i zweryfikować nowy VCS w małym pobocznym projekcie. Wybierz kilku „alfa” programistów, którzy są gotowi wypróbować nowe rzeczy i nie przeszkadza ci zebranie szeregu nieudanych eksperymentów. Kiedy skunk-works jest w stanie zademonstrować BETONOWE niezaprzeczalne usprawnienia w przepływie pracy, wtedy możesz spróbować wdrożyć go do reszty zespołu i masz kilku ewangelistów, którzy ci w tym pomogą.

(*) przez „nowy VCS” niekoniecznie mam na myśli mercurial lub git, może to być również SVN (poprawnie wykonane).