Czy SVN jest nieaktualny? [Zamknięte]


9

Minęło zaledwie kilka lat, odkąd przeprowadziłem migrację z Visual Source Safe do SVN. A dla mnie SVN jest nadal trochę „WOW! Mogę robić tak wiele rzeczy! SVN jest taki fajny!”

Ale wiele osób wokół mnie mówi: „SVN? Naprawdę? Meh ...”

I jest ich tak wiele, że się martwię. Czy powinienem przenieść swój zespół do Git / Mercurial lub innej wymyślnej rzeczy? Wiem, że brzmię absurdalnie, a oczywistą odpowiedzią byłoby „pozostać z tym, co dla ciebie działa”. SVN działa dla mnie ... Ale za każdym razem, gdy tworzę nowy projekt w moim repozytorium, zadaję sobie pytanie - może to był czas na przeprowadzkę?

Więc ... Czy SVN jest naprawdę taki zły? Czy tęsknię za ogromną szansą?



Czy jesteś samodzielnym programistą?
TeaDrinkingGeek

6
Zawsze korzystałem z GIT. Teraz muszę używać SVN w pracy .... ... ... ... ... ... ... RAGE.
Ivo Wetzel,

@TeaDrinkingGeek: OP mówi „powinienem przenieść mój zespół ...”, więc zgaduję, że w grę wchodzi coś więcej niż tylko OP (chyba że liczysz zespół jednego zespołu - ale wtedy zwykle nie jest to określane jako „mój zespół” ).
FrustratedWithFormsDesigner

lol przepraszam kolego, oczy są trochę zamazane po 12 godzinach na laptopie. :)
TeaDrinkingGeek

Odpowiedzi:


8

Zależy to całkowicie od użytkowania.

Jeśli masz jeden zespół ludzi w pokoju i wykonują oni tam większość swojej pracy, jeśli masz proces kompilacji i wdrażania, który już lubisz, i jeśli nie chcesz udostępniać swojego kodu innym osobom (tak jak w przypadku projekt open source), więc nie powinieneś się przejmować.

Rok temu przestawiłem się z Subversion na git. Git doskonale nadaje się również do tego głównie lokalnego zastosowania, ale tam, gdzie naprawdę świeci, jest rozproszony rozwój. Używana lokalnie, miło jest mieć github jako zdalną kopię zapasową i ładny interfejs sieciowy do kodu, a także ułatwia mi udział kontrahentów. Ale teraz nie czerpię z tego zbyt wiele, ponieważ nie czerpałem z Subversion.


8

Nie daj się porwać ciągłemu strumieniu hipesów. Masz coś, co działa, używaj go, dopóki nie pojawi się wymóg biznesowy, który lepiej spełnia coś innego (nie, nowy błyszczący system kontroli źródła lub język programowania co kilka miesięcy, za każdym razem, gdy pojawi się coś „nowego i ulepszonego”, NIE pójdzie aby sprostać wymaganiom biznesowym lepiej niż obecnie).

Jeśli SVN działa dla Twojej organizacji, nie ma powodu do inwestowania pieniędzy / czasu / wysiłku potrzebnego do przejścia na coś innego, jakkolwiek niektórzy chcą, ponieważ jest nowy i błyszczący.

I nie, nie jest to (jak myśli JBK) decyzja, która powinna zależeć od „zespołu”, jest to decyzja, która należy do zarządzania po konsultacji ze wszystkimi zainteresowanymi stronami (w tym co najmniej twoimi administratorami). Wydawanie pieniędzy na zmianę stosu technologii jest decyzją biznesową, a nie decyzją techniczną.


Głosowałbym za tobą milion razy, gdybym mógł.
HLGEM

5

Uważam, że nigdy nie należy podejmować decyzji z niewiedzy. Jeśli nie wiesz, czego brakuje, powinieneś spróbować wyjść wystarczająco długo, aż to zrobisz, możesz podjąć świadomą decyzję. Skoku do kontroli rozproszonej tak naprawdę nie da się zrozumieć bez wypróbowania go i porzucenia starych nawyków. Większość mocy DVCS polega na tym, że możesz utworzyć dowolną liczbę oddziałów z dowolnego powodu. Jeśli wypróbujesz go przez miesiąc i nie utworzyłeś co najmniej 5 oddziałów, nie przetestowałeś go na własnych warunkach. Jest to błąd większości ludzi, którzy nie dostają „dupka”. Następnie, jeśli wrócisz do svn, przynajmniej będziesz znać powody dla siebie.


5
Jestem zdecydowanie za podejmowaniem większości decyzji na podstawie względnej ignorancji. Sugerujesz, żeby poświęcił miesiąc na wypróbowanie git. To prawdziwa praca. Powinien to zrobić tylko wtedy, gdy istnieje powód, by sądzić, że poprawi to jego sytuację. W przeciwnym razie jest prawdopodobnie coś, na czym powinien spędzić miesiąc eksperymentów. Np. Redis, mongo, szyny, node.js lub BDD, którekolwiek z równie gorących nowych rzeczy.
William Pietri

Ale Git to nowa, gorąca rzecz. Doświadczenie wielu użytkowników Gita sugeruje, że poprawi to jego sytuację.
Kyralessa

3

Nie korzystałem z Gita, ale używałem Mercurial i naprawdę nie rozumiem, o co chodzi. Wygląda to jak SVN, z tą różnicą, że podstawowe rzeczy, takie jak zameldowanie i kasa, są bardziej skomplikowane (wymaga dwóch kroków zamiast jednego). W zamian ma to na celu zrobienie dużo bardziej zaawansowanych rzeczy, których tak naprawdę nigdy nie potrzebowałem, aby zrobić o wiele łatwiej. Moja reakcja na twierdzenia, że ​​DVCS jest w jakiś sposób z natury lepsza, brzmi: „OK, jasne, wezmę za to słowo”, a następnie kontynuuję pracę z SVN, który działa dobrze dla mnie.


Ogromną zaletą DVCS jest to, że możesz wykonywać całą pracę „offline”. Ta jedna cecha nakłada wymóg, aby DVCS posiadał potężny mechanizm scalania, który może obsługiwać zmianę bazy i rozgałęzianie; zadania, które po prostu nie są możliwe przy scentralizowanym VCS. Przewaga ludzi wynika z włączonych przepływów pracy, a nie z technicznej przewagi. Jeśli nie używasz lub nie potrzebujesz tego rodzaju przepływu pracy, to też jest w porządku.
greyfade

1
Dzieje się tak, ponieważ rejestracja i kasa nie istnieją w DVCS. Używasz hg jako zamiennika SVN zamiast hg w sposób, w jaki ma być używany. To samo dotyczyłoby dowolnego DVCS.
alternatywny

@ Mathepic: Możesz zmienić nazwę, jeśli chcesz, ale podstawowa koncepcja przesyłania danych między lokalną kopią roboczą a oficjalnym repozytorium istnieje w dowolnym systemie kontroli źródła.
Mason Wheeler,

1
nie. W DVCS nie ma takiej operacji.
alternatywny

3
tak, istnieje - centralne repozytorium, aby przerzucić wersję „master”, jest bardzo ważnym przypadkiem użycia, zarówno do tworzenia kopii zapasowych, kompilacji serwera, zarządzania wydaniami, lub po prostu sposobem na lepszą koordynację między zespołami.
gbjbaanb 9.11.11

-2

Oczywistą odpowiedzią na to pytanie jest pozwolenie zespołowi na podjęcie decyzji i dyskusja na temat najlepszej opcji dla wszystkich, aby nikt nie dzwonił w próżni. Mogą być różne opinie i obawy, którymi należy się zająć, ale wolałbym raczej znaleźć odpowiedź na konsensus, niż starać się dyktatorsko decydować o tym, czego użyć.


3
Czy masz pojęcie o koszcie roboczogodzin przejścia z jednego systemu kontroli źródła na inny lub ryzyku utraty rzeczy w procesie, jeśli ktoś nowy w nowym systemie popełni błąd podczas konwersji istniejącego kodu? To NIE jest decyzja zespołowa, jest to decyzja biznesowa i powinna być podejmowana tylko wtedy, gdy masz rzeczywiste potrzeby, których obecny system nie może zaspokoić.
HLGEM
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.