Ist SVN nicht in Mode? [geschlossen]


9

Es ist erst einige Jahre her, seit ich von Visual Source Safe zu SVN migriert bin. Und SVN ist für mich immer noch ein bisschen "WOW! Ich kann so viele Dinge tun! SVN ist so cool!"

Aber viele Leute um mich herum sagen immer wieder "SVN? Wirklich? Meh ..."

Und es gibt so viele von ihnen, dass ich mir Sorgen mache. Soll ich mein Team auf Git / Mercurial oder eine andere schicke Sache verlegen? Ich weiß, ich klinge lächerlich und die offensichtliche Antwort wäre "bleib bei dem, was für DICH funktioniert". SVN funktioniert für mich ... Aber jedes Mal, wenn ich ein neues Projekt in meinem Repository erstelle, frage ich mich: Vielleicht war dies die Zeit, umzuziehen?

Also ... Ist SVN wirklich so schlimm? Verpasse ich eine große Chance, wenn ich dabei bleibe?


Dies könnte eine interessante Lektüre sein: stackoverflow.com/questions/161541/svn-vs-git
fouronnes

Sind Sie ein eigenständiger Entwickler?
TeaDrinkingGeek

6
Ich habe immer GIT benutzt. Jetzt muss ich SVN bei der Arbeit verwenden .... ... ... ... ... ... ... RAGE.
Ivo Wetzel

@TeaDrinkingGeek: OP sagt "Soll ich mein Team bewegen ...", also schätze ich, dass es mehr als nur das OP gibt (es sei denn, Sie zählen ein Team von einem pro Team - aber dann wird es normalerweise nicht als "mein Team" bezeichnet. ).
FrustratedWithFormsDesigner

lol sorry Kumpel, die Augen sind nach 12 Stunden auf dem Laptop etwas verschwommen. :)
TeaDrinkingGeek

Antworten:


8

Es hängt ganz von der Nutzung ab.

Wenn Sie ein Team von Personen in einem Raum haben und diese den größten Teil ihrer Arbeit dort erledigen, wenn Sie einen Build- und Bereitstellungsprozess haben, den Sie bereits mögen, und wenn Sie Ihren Code nicht mit anderen Personen teilen möchten (wie Sie es mit einem tun würden) Open Source Projekt), dann sollten Sie es nicht schwitzen.

Ich habe vor vielleicht einem Jahr von Subversion zu Git gewechselt. Git ist auch für diesen meist lokalen Anwendungsfall vollkommen geeignet, aber wo es wirklich glänzt, ist die verteilte Entwicklung. Bei lokaler Verwendung ist es schön, Github als Remote-Backup und hübsches Webinterface für den Code zu haben, und es macht es mir einfach, Auftragnehmer teilnehmen zu lassen. Aber ich habe momentan nicht viel davon, was ich nicht von Subversion bekommen habe.


8

Lassen Sie sich nicht vom ständigen Strom der Hypes mitreißen. Sie haben etwas, das funktioniert, verwenden Sie es so lange, bis es eine Geschäftsanforderung gibt, die besser mit etwas anderem erfüllt wird (nein, ein glänzendes neues Versionsverwaltungssystem oder eine Programmiersprache alle paar Monate, wenn etwas "Neues und Verbessertes" hochgespielt wird, wird NICHT ausgeführt um Ihre Geschäftsanforderungen besser zu erfüllen als die, die Sie jetzt verwenden).

Wenn SVN für Ihr Unternehmen funktioniert, gibt es daher keinen Grund, das Geld / die Zeit / den Aufwand zu investieren, die erforderlich sind, um zu etwas anderem zu wechseln, wie sehr einige Leute dies auch möchten, weil es neu und glänzend ist.

Und nein, das ist keine Entscheidung (wie JBK meint), die dem "Team" überlassen bleiben sollte. Es ist eine Entscheidung, die dem Management nach Rücksprache mit allen interessierten Parteien (einschließlich Ihrer Systemadministratoren) überlassen bleibt. Es ist eine geschäftliche Entscheidung, Geld für die Änderung Ihres Technologie-Stacks auszugeben, keine technische Entscheidung.


Ich würde dich millionenfach unterstützen, wenn ich könnte.
HLGEM

5

Ich glaube, man sollte niemals Entscheidungen aus Unwissenheit treffen. Wenn Sie nicht wissen, was Sie vermissen, sollten Sie lange genug versuchen, bis Sie dies tun, dann können Sie eine fundierte Entscheidung treffen. Der Sprung zur verteilten Kontrolle kann nicht wirklich verstanden werden, ohne ihn auszuprobieren und dabei einige alte Gewohnheiten loszulassen. Der größte Teil der Leistung von DVCS besteht darin, dass Sie so viele Zweige erstellen können, wie Sie möchten, aus welchem ​​Grund auch immer Sie möchten. Wenn Sie es einen Monat lang ausprobiert haben und nicht mindestens 5 Filialen erstellt haben, haben Sie es nicht zu seinen eigenen Bedingungen getestet. Dies ist der Fehler der meisten Leute, die keinen Git "bekommen". Wenn Sie danach zu svn zurückkehren, kennen Sie zumindest die Gründe für sich.


5
Ich bin stark dafür, die meisten Entscheidungen aus relativer Unwissenheit zu treffen. Sie schlagen vor, er braucht einen Monat, um Git auszuprobieren. Das ist echte Arbeit. Er sollte das nur tun, wenn es einen Grund zu der Annahme gibt, dass dies seine Situation erheblich verbessern wird. Ansonsten gibt es wahrscheinlich noch etwas, an dem er seinen Monat lang experimentieren sollte. ZB Redis oder Mongo oder Rails oder Node.js oder BDD eines der ebenso heißen neuen Dinge.
William Pietri

Aber Git ist eine heiße neue Sache. Und die Erfahrung vieler Git Benutzer legt nahe , es wird seine Situation besser viel zu machen.
Kyralessa

3

Ich habe Git nicht verwendet, aber ich habe Mercurial verwendet, und ich sehe wirklich nicht, was die große Sache ist. Es fühlt sich sehr nach SVN an, nur dass grundlegende Dinge wie Ein- und Auschecken komplizierter sind (erfordert zwei Schritte anstelle von einem). Im Gegenzug soll es viel fortgeschritteneres Zeug machen, das ich eigentlich nie viel einfacher machen musste. Meine Reaktion auf die Behauptung, DVCS sei von Natur aus überlegen, lautet im Grunde: "OK, sicher, ich nehme Ihr Wort dafür", und dann mache ich mit SVN weiter, was für mich gut funktioniert.


Das große Problem bei DVCS ist, dass Sie Ihre gesamte Arbeit "offline" erledigen können. Diese eine Funktion setzt voraus, dass das DVCS über einen leistungsstarken Zusammenführungsmechanismus verfügt, der das Umbasieren und Verzweigen handhaben kann. die Art von Aufgaben, die mit einem zentralen VCS einfach nicht möglich sind. Die Überlegenheit, die Menschen behaupten, beruht eher auf den aktivierten Workflows als auf der technischen Überlegenheit. Wenn Sie einen solchen Workflow nicht verwenden oder benötigen, ist das auch in Ordnung.
Greyfade

1
Das liegt daran, dass das Ein- und Auschecken in DVCS nicht vorhanden ist. Sie verwenden hg als Ersatz für SVN, anstatt hg so zu verwenden, wie es verwendet werden soll. Gleiches gilt für jedes DVCS.
Alternative

@Mathepic: Nun, Sie können den Namen ändern, wenn Sie möchten, aber das grundlegende Konzept der Datenübertragung zwischen der lokalen Arbeitskopie und dem offiziellen Repository existiert in jedem Versionsverwaltungssystem.
Mason Wheeler

1
Nein, tut es nicht. In einem DVCS gibt es keine solche Operation.
Alternative

3
Ja, das ist der Punkt, an dem ein zentrales Repo die "Master" -Version auf einen sehr gültigen Anwendungsfall überträgt, entweder für Backup, Build-Server, Release-Management oder einfach nur für eine bessere Koordination zwischen Teams.
Gbjbaanb

-2

Die offensichtliche Antwort hier ist, das Team entscheiden zu lassen und eine Diskussion darüber zu führen, was für alle die beste Option ist, damit nicht jemand im luftleeren Raum das Sagen hat. Es mag verschiedene Meinungen und Bedenken geben, die angesprochen werden müssen, aber ich würde eher vorschlagen, eine Konsensantwort anzustreben, als zu versuchen, diktatorisch zu sein, was zu verwenden ist.


3
Haben Sie eine Vorstellung von den Kosten in Mannstunden für den Wechsel von einem Versionsverwaltungssystem zu einem anderen oder von dem Risiko, dabei Dinge zu verlieren, wenn jemand, der neu im neuen System ist, einen Fehler bei der Konvertierung von vorhandenem Code macht? Dies ist KEINE Teamentscheidung, dies ist eine Geschäftsentscheidung und sollte nur getroffen werden, wenn Sie echte Anforderungen haben, die Ihr aktuelles System nicht erfüllen kann.
HLGEM
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.