Wie man ein Unternehmen davon überzeugt, seine Quellcodeverwaltung zu ändern [geschlossen]

Question

Mein jetziger Arbeitsplatz befindet sich derzeit in einem Umbruch, ein neuer Eigentümer hat übernommen, die Dinge werden endlich standardisiert und die richtigen Richtlinien werden durchgesetzt.

Aber wir verwenden immer noch VSS. Es gibt wirklich keinen Grund, es zu verwenden, außer dem, was ursprünglich eingerichtet wurde.Wir verwenden kein Visual Studio oder ein Tool, das dies ausdrücklich erfordert.

Was wäre das absolut beste Argument, das ich vorbringen kann, um sie davon zu überzeugen, dass der Umstieg auf etwas wie Subversion auf lange Sicht eine viel bessere Lösung wäre?

Answer 1

VSS verlässt sich bei der Verwaltung der Datenbank vollständig auf die Clients.Wenn ein Client während eines Schreibvorgangs über das Netzwerk zum falschen Zeitpunkt die Verbindung trennt, wird Ihre Datei auf dem Server gelöscht.Nicht nur der Tipp, sondern die ganze Geschichte.Ich hoffe, Sie haben ein gutes Backup.Ich habe es durchgemacht.Es sind schlechte Nachrichten.

Die VSS-Nutzung über VPN oder andere Remoteverbindungen ist miserabel.Zur Übertragung der Daten wird SMB verwendet, und Sie müssen die Datei und alle ihre Deltas abrufen, um den Tipp zu erhalten.Böse.

Ich habe gesehen, dass VSS bei 1 GB Daten anfängt zu reagieren.Datenbankfehler usw.MS (irgendwo in einer FAQ oder KB) sagt, dass 2 GB tatsächlich die maximale Sicherheitsgrenze sind.Es gibt keine guten Managementinstrumente (die Klienten leiten die Anstalt), sodass Sie diesbezüglich keine wirkliche Warnung erhalten.

Irgendetwas Mit einem Serverprozess, der ein gewisses Maß an Transaktionen und Integritätskontrolle bietet, ist dies eine überlegene Lösung.

Answer 2

Das beste Argument müsste der Grund sein, warum Sie möchten, dass sie auf Subversion umsteigen.:) :)

Ich weiß absolut nichts über VSS, aber mir kommt der Satz „Wenn es nicht kaputt ist, repariere es nicht“ in den Sinn.Sie müssen Ihren Managern zeigen, dass VSS defekt ist und repariert werden muss.Noch besser ist es, wenn Sie dem Management zeigen können, wie es dadurch Geld sparen kann.

Answer 3

@Adam Davis:Uhhh, eigentlich Adam, VSS ist ein schreckliches Versionsverwaltungssystem.Es hat eine lange Geschichte der Beschädigung des Verlaufs und des Datenverlusts.Es ist schlecht beim Zusammenführen, kann nicht gut mit mehreren Entwicklern umgehen und ist sehr langsam.Auch die Geschichte ist dürftig.Microsoft unterstützt es nicht mehr wirklich. Sie werden feststellen, dass sie es nie für ihre eigene interne Entwicklung verwendet haben und es jetzt nicht einmal zugunsten einer moderneren Lösung (VSTS) verkaufen.Kurz gesagt: Wenn Sie sich zwischen VSS und einer anderen Art der Quellcodeverwaltung entscheiden müssen, entscheiden Sie sich für die Alternative.

Answer 4

Wenn Sie nur die Funktionen durchgehen, die eine gute Quellcodeverwaltung mit sich bringt:

• Möglichkeit, problemlos Protokolle darüber anzuzeigen, wer was, wann und in welcher Reihenfolge mit welchen Dateien gemacht hat
• Führen Sie einen Verlauf früherer Versionen von allem
• Gehen Sie einfach zurück und reproduzieren Sie eine bestimmte Version Ihrer Dateien aus einer früheren Version, um in älteren Versionen gemeldete Fehler einfacher zu reproduzieren
• Sie haben die Möglichkeit, gelöschten Code abzurufen oder unerwünschte Änderungen zu entfernen, ohne dabei befürchten zu müssen, dass Daten verloren gehen

Answer 5

Jedes Dokument, das den Wechsel belegt, senkt die Kosten.Andernfalls gibt es mehrfarbige Grafiken und Diagramme.Vielleicht eine Powerpoint-Präsentation.

Answer 6

Das Internet ist übersät mit gut geschriebenen Artikeln über die Mängel von VSS.Ich würde dies als Beweis für die Abkehr von VSS sammeln.Finden Sie eine wichtige Anforderung, die VSS nicht unterstützen kann (Fernarbeit, Unterstützung auf anderen Betriebssystemen, Tool-Integration) und nutzen Sie sie, um Ihr Problem voranzutreiben.Anschließend müssen Sie ein Versionsverwaltungssystem finden, das den Anforderungen Ihrer Organisation gut entspricht. Sind Sie sicher, dass Subversion dieses System ist?Richten Sie eine Demonstration des von Ihnen gewählten Systems ein und beweisen Sie damit dessen Wertigkeit.

Ich habe diese Änderung bei einem früheren Arbeitgeber implementiert (zuerst zu CVS und dann zu SVN), und obwohl sie erfolgreich war, mussten wir viele Teile am Rande aufbauen und uns auf viele (manchmal unzuverlässige) Open-Source-Projekte verlassen, um sie zu bekommen alle Werkzeuge, die wir brauchten.Im Nachhinein hätte ich darüber nachdenken sollen, professionelle Tools wie Perforce, Vault oder sogar Team System zu evaluieren.Nachdem ich diese bewertet hatte, hätte ich ein angemessenes Urteil darüber fällen können, ob CVS/SVN ihren „kostenlosen“ Preis wert waren.

Answer 7

Die Fähigkeit, mit Verzweigungen und Gabelungen umzugehen, ist ein Anfang.

Versuchen Sie, Subversion eine Zeit lang parallel zu vss zu verwenden. Sie werden höchstwahrscheinlich viele Argumente finden, um Ihren Chef zu überzeugen.Wenn Sie dies nicht tun, hat Ihr Chef Recht, es gibt keinen Grund, zu wechseln.

Answer 8

Lassen Sie sie bei Google nach „VSS-Problem“, „Source Safe Corruption“ suchen oder suchen Sie einfach auf der Wiki-Seite danach.Das sollte sie davon überzeugen, dass es für Sie auf lange Sicht wahrscheinlich nicht rentabel ist, auf einen so wichtigen Teil Ihres Geschäfts zu setzen.

Wie groß ist Ihr Team?(Das heißt, ich meine, wie viele Mitglieder es gibt, nicht, ob Sie Salatschwärmer sind oder nicht) Sobald Sie anfangen, mehr als ein halbes Dutzend ziemlich aktive Benutzer zu haben, wird Ihnen VSS Kopfschmerzen bereiten.

Ich bezweifle ernsthaft, dass Microsoft es verwendet (nutzen sie nicht tatsächlich eine angepasste Subversion- oder CVS-Variante?), und Sie müssen sich fragen: Wenn das Unternehmen kein eigenes Hundefutter isst, warum sollten Sie es dann essen?

Answer 9

Die grundlegende Antwort lautet: Sie müssen sicherstellen, dass der Wechsel den Anforderungen des Unternehmens entspricht.Zum Beispiel:

1. geringere Entwicklungskosten
2. kürzerer Zeitplan (eine andere Nuance von Nr. 1)
3. Geeigneter für die Erfüllung von Prozessanforderungen (z. B. Rückverfolgbarkeit von Softwareanforderungen oder Build-Reproduzierbarkeit usw.).

Die Argumentation zu diesen Dingen erfordert auch etwas Quantitatives und nicht nur „Wir werden die Kosten senken, weil das der Fall ist“. Rechts Art und Weise, es zu tun!".

Eine Sache, auf die Sie achten sollten, ist, dass es für einen Entwickler zu einfach ist, sich selbst davon zu überzeugen, dass eine Änderung von Vorteil wäre, ohne zuvor die grundlegenden Geschäftsfilter durchzugehen.Sobald das geschieht, sind die Entwickler mit ihren Tools unzufrieden und doppelt frustriert, weil sie denken, dass das Management nicht zuhört.Wenn Sie eines der oben genannten Dinge nicht abhaken können, haben Sie keine Chance, das Management von irgendetwas zu überzeugen (es sei denn, das Management ist inkompetent, aber das ist eine andere Frage).

Answer 10

Warum Subversion statt VSS?

• Gratis Software
• Einfacher zu verwalten
• „Check-Ins“ sind atomar!
• Einfach zu verzweigen und zusammenzuführen
• Weiterentwicklung (d. h.VSS ist Sackgasse)
• Bessere Tools zum Verfolgen von Änderungen und Anzeigen von Protokollen
• Toolset- und plattformunabhängig, lässt sich aber auch in viele Tools integrieren

Ich habe den Vorschlag meinem Vorgesetzten gemacht, und es war ziemlich einfach, ihn zu verkaufen.Ich habe festgestellt, dass es viel einfacher zu verwenden ist, insbesondere für Verzweigungen (das „Freigeben und Anheften“ unseres Projekts in VSS dauerte 5 Stunden, und dann nahm jeder Vorgang zusätzliche Zeit in Anspruch!).

Answer 11

Ich habe zuvor geschrieben darüber, warum VSS keine gute Idee ist.Vielleicht können Sie daraus einige Informationen gewinnen.Auch Dieser Artikel Und Dieses hier weitere Informationen enthalten.

VSS 2005 hat einige der Risse in 6.0 überdeckt, allerdings nicht auf besonders überzeugende Weise.Das gleiche hirntote Fundament bleibt bestehen.

Answer 12

Auch wenn es nicht kaputt ist, bietet die Migration von VSS potenzielle Vorteile.Erstens und am trivialsten ist, dass Sie keine neuen VSS-Lizenzen kaufen müssen.Zweitens gibt es viele Beispiele für Mängel im VSS-Produkt (einige wurden auch von MS anerkannt).Die Lernkurve für SVN ist mindestens so niedrig wie für VSS, und wenn Entwickler mit ihrem Versionsverwaltungssystem zufriedener sind, ist es wahrscheinlicher, dass sie es früh und häufig verwenden.Das bedeutet für Ihr Unternehmen ein wesentlich geringeres Risiko, und das ist ein großer Vorteil.

Answer 13

@Jason:VSS ist kaputt.

Ich denke, die wirksamste Methode, um eine Abkehr von VSS zu motivieren, besteht darin, darauf hinzuweisen, wie wichtig Ihr Quellcode ist.Mit seiner Integrität Risiken einzugehen, ist keine kluge Geschäftsentscheidung.

Fügen Sie hinzu, dass Ihre Programmierer die Ersteller dieses Assets sind und dass eine einfachere Produktivität für sie einen höheren Wert Ihres Quellcode-Assets bedeutet.Joel on Software spricht oft darüber, dass die Investition in seine Programmierer ein großer Gewinn für sein Unternehmen ist.

Die anderen Antworten hier beschreiben alle spezifische Gründe, auf die Sie bei Ihrer Argumentation hinweisen können.

Answer 14

Zusätzlich zu den technischen Punkten, die in anderen Antworten angeführt werden, kann es auch nicht-technische Gründe geben, auf die Sie vorbereitet sein sollten:

Sie sollten untersuchen, ob Ihr Unternehmen Richtlinien gegen Open-Source-Software hat (oder fehlgeleitete Ängste davor hat).Wenn das Unternehmen oder seine Anwälte nicht verstehen, welche Lizenzen proprietären Code „infizieren“ und welche nicht, und auch nicht wissen, was Sie mit Open-Source-Code tun können, der Ihren proprietären Code nicht beeinträchtigt, werden Sie es tun Es fällt ihnen schwer, sie dazu zu bringen, von einem proprietären zu einem Open-Source-Tool zu wechseln.(Und Sie haben möglicherweise einen größeren Bildungsauftrag vor sich.)

Bei der Argumentation für den Wechsel von proprietären (z. B.VSS) zu Open Source (z.B.Subversion) müssen Sie auch darauf vorbereitet sein, die Qualität des Codes und das Fehlen jeglicher Notwendigkeit einer Garantie oder anderer Vertragsrechte in Bezug auf den Code zu verteidigen.