Nachdem ich den ganzen Morgen damit verbracht hatte, etwas einzuchecken, wurde mir klar, dass ich ein paar Arbeitstage verloren habe.

Das ist schon mal passiert - und ist anscheinend bei SourceSafe weit verbreitet. Kann SourceSafe ohne Probleme erfolgreich verwendet werden und wenn ja, wie?

Meine Ansicht ist einfach, migrieren Sie so schnell wie möglich zu etwas anderem. Es wird nicht lange dauern (1-2 Wochen WAG) und egal wie lange die Migration dauert, es ist einfach, dies für das Management zu rechtfertigen. Eine kurze Migrationszeit bedeutet eine solide Quellcodeverwaltung und eine sehr geringe Wahrscheinlichkeit, dass Quellcode verloren geht. Führen Sie eine schnelle Google-Suche nach "Source Safe Horror Stories" oder ähnlichem durch, wenn Ihr Chef skeptisch ist.

Am schlimmsten. SCM. Je.

Alles, was in SCM falsch ist, ist in VSS enthalten. Sogar StarTeam ist besser als Source Safe. Source Safe ist der Internet Explorer 1 der Welt der Versionskontrolle, der von keiner anderen Implementierung abgelöst wird.

Wie habe ich es benutzt?

Mein typischer Workflow, um Dinge zu erledigen, war

1. Überprüfen Sie das Projekt
2. Sperren Sie alle Dateien (um zu vermeiden, dass sie mit anderen zusammengeführt werden, die die unheiligen Tore der Hölle geöffnet haben).
3. Hat meine Arbeit gemacht
4. Jeder Tag überprüfte meine Änderungen in
5. Überprüfte alles noch einmal und behebte alle Probleme mit der Integration
6. Habe es wieder eingecheckt

Im Vergleich zu Subversion ist das oben Genannte lächerlich (abgesehen davon, dass Sie überprüft haben, dass Sie den Build nicht gebrochen haben).

Einschränkungen der Programmierpraktiken meines Teams

Dies sind die Regeln, nach denen das Team arbeiten musste, damit es für uns funktioniert. Ihr Kilometerstand kann variieren.

1. Eine Datei darf nur von einer Person bearbeitet werden (Himmel hilft Ihnen, wenn sie in den Urlaub fahren)
2. Verzweigen Sie nicht, es ist zu schwer zu verwalten
3. Versuchen Sie niemals, zu einer früheren Revision zurückzukehren

Was kann getan werden?

Polarion verfügt über eine Reihe guter Tools für die Migration von Source Safe nach Subversion (SVN), dem aktuellen De-facto-Standard für Open Source-Versionskontrolle in den meisten Unternehmen. Subversion leidet unter der Anforderung, dass ein Server verfügbar sein muss, um das Einchecken zu ermöglichen (im Gegensatz zu GIT oder Mercurial, die für verteilte Offline-Teams entwickelt wurden).

Ändere deine Quellcodeverwaltung auf SVN / Mercurial / Git und schaue niemals zurück!

Wir haben es vor etwa einem Jahr außer Betrieb genommen.

Es passierte mehrmals, dass das, was ich am Vorabend eingecheckt hatte, am nächsten Morgen einfach nicht da war. Ich fand das nicht amüsant, weil es verdächtig aussah, als hätte ich meine Arbeit einfach nicht beendet. Da ich neu in der Firma war, war es für mich möglicherweise gefährlich.

Wir sind zum TFS gewechselt und es funktioniert seitdem reibungslos.

Meine Sicht?

Es gibt bessere, die einfacher zu verwenden, sicherer zu verwenden und völlig kostenlos sind. Warum sollte man es überhaupt benutzen?

Dies ist ein Entwicklungsbereich, in dem wir eine große Auswahl haben. die meisten oder alle besser als VSS.

• Subversion
• Mercurial
• Git
• Mehr

Die Verwendung von SourceSafe in einem kommerziellen Betrieb ist wie das Heizen des Gebäudes durch Verbrennen von Dollarnoten.

Im Jahr 2000 verlor mein Unternehmen mit acht Entwicklern wahrscheinlich 5-10% seiner Produktivität, weil VSS-Datenbanken durchschnittlich zweimal täglich beschädigt wurden. Es war nur so niedrig, weil wir stündliche Backups durchgeführt hatten.

Seitdem ich von VSS zu Perforce, svn und git gewechselt bin, ist noch nie eine SCM-Datenbank beschädigt worden.

Ich kann auf diese runter zur Hölle gewählt bekommen, aber ..

VSS bringt Sie effektiv auf Trab, insofern, als Sie keinerlei Realität in Einklang bringen können, die erforderlich ist, um zu erkennen, dass Ihr jetzt gegabeltes Repo nicht Ihre Schuld war.

Bitte, benutze es niemals.

Ich habe es jahrelang benutzt - es war die Standardlösung, da es bereits da war. Hatte mich schon einige Male gebissen, aber Trägheit ist schwer zu überwinden

dann musste ich es über VPN aus der Ferne verwenden, und selbst kleinere Eincheckvorgänge waren so, als würde man einen Ziegelstein durch ein Loch stopfen . Es war schneller, die geänderten Dateien manuell zu finden, sie zu komprimieren, per E-Mail zu versenden, auf dem Quell-Vault-Computer zu speichern, zu entpacken und den Code vom Quell-Vault-Computer einzuchecken.

Auf Mercurial umgestellt. Ich kann die gesamte Quellcodebasis in weniger als einer Minute über das VPN klonen. Und ich fürchte mich nicht mehr vor Verzweigungen.

Ich gehe nie zurück.

Es ist ein Gräuel. Aber immer noch besser als nichts.

Ich habe es für eine lange Zeit (fast 10 Jahre) verwendet, ohne jemals persönlich Probleme zu haben (auch in den Teams, in denen ich gearbeitet habe, obwohl unser Code in der Regel ziemlich gut aufgeteilt war, um Konflikte und ähnliches zu vermeiden).

Es gibt jedoch viel zu viele Berichte über Datenverluste, um sie weiterhin nutzen zu können, wenn es vernünftige, zuverlässige Open-Source-Alternativen gibt.

Bearbeiten: Aus den Kommentaren geht hervor, dass die Nachricht alles Komplexe zu vermeiden scheint (Verzweigen, Zusammenführen, Konflikte), und Ihnen geht es wahrscheinlich gut. Alles andere und Sie betreten riskantes Terrain.

Sogar MS lehnen es zugunsten von TFS ab.

Für ein Solo oder einen wirklich kleinen Laden, der in Visual Studio 6 oder etwas älter arbeitet, ist es passabel und besser als nichts. Ich denke, es gibt eine Menge Übertreibung darüber, wie schlimm es war, aber dann ist es nur ein einziges Mal erforderlich, wertvolle Arbeit zu verlieren, um Sie an einem Produkt zu säuern (aus gutem Grund). VSS hatte seinen Platz, und ich begrüße es, dass es zumindest viele Entwickler ermutigte, die überhaupt kein SCM-Tool verwendeten, um sich an die Gewohnheit zu gewöhnen, aber wie viele Technologien ist es mittlerweile ziemlich veraltet.

Nachdem ich es 3 Jahre lang verwendet habe und mich wegen all der fortschrittlicheren / rationaleren Alternativen bei meinem Manager immer wieder beschwert habe, hatte ich nie wirklich ein Problem mit VSS, aber ich hatte auch nie eine Option.

Meine Meinung ist, dass es sowohl saugt als auch bläst.

Das nervigste daran ist nicht die schreckliche Versionierung und die verwirrende Verzweigungsfähigkeit, aber das Listenfeld im Dateimenü lässt Sie nicht die rechte Pfeiltaste zum Erweitern drücken.

Wirklich schmerzhaft.

Meine Sicht auf VSS? Ich lehnte einige Stellenangebote ab (sehr gut bezahlt), weil sie "VSS-Kenntnisse" verlangten. Und ich bin sicher, es gibt ein paar andere Leute, die dasselbe getan haben.

Sie leiden nicht nur unter dem Problem einer möglichen Quellenbeschädigung (die für das Management als Argument ausreichend sein sollte, um sie zu ersetzen), sondern Sie müssen auch mit umständlichen Backups und der Unfähigkeit leben, in verschiedenen Arbeitsströmen effektiv als Team zu arbeiten.

Suchen Sie einen anderen SCM (einen anderen) und schauen Sie sich an, wie einfach das Verzweigen und Zusammenführen sein kann. Denken Sie an die Zeiten, in denen Sie Dateien aus Ihrer VSS-Lösung kopieren und an einem anderen Ort aufbewahren mussten, während Sie einen Fehler im Produktionscode behoben haben.

Installieren Sie für Kicks einfach GIT - zeigen Sie auf Ihre VSS-Dateien und sehen Sie, wie einfach es für GASP zwei Programmierern ist, gleichzeitig an verschiedenen Teilen derselben Datei zu arbeiten, und lassen Sie dann die Software Ihre Änderungen intelligent zusammenführen ... SCM Tools sollten mehr sein als nur Quell-Backup.

Meine Ansichten zu VSS? Ich habe es für eine lange Zeit regelmäßig verwendet (immer noch gelegentlich für ältere Komponenten verwendet), aber es ist zu XX Jahrhundert für unser Team:

• Sehr unzuverlässig
• Nicht verwendbare Zweige
• Sehr schlechte Versionierungsunterstützung, Sie haben Labels, sind aber (genau wie Zweige) nicht wirklich verwendbar

Ich bin mit all dem oben Genannten einverstanden: Wählen Sie eine der besseren Open-Source-Alternativen (auch alte CVS) oder, wenn Ihr Unternehmen eine Art MSDN-Abonnement hat, TFS .

• Die Standardverriegelung verlangsamte die Entwicklung, und niemand wollte sich mit der Einrichtung herumschlagen
• Es lässt sich nicht sehr gut in andere Dienste integrieren, zum Beispiel in eine Projektmanagement-Webanwendung
• Mit unserem geplanten CI-Server würde es nicht gut funktionieren

Das neue 2010 Team Foundation-Zeug sollte viel helfen und versuchen, den schlechten Teilen von VSS zu entkommen. Im Kern ist es jedoch immer noch auf VSS angewiesen , weshalb wir zu SVN gewechselt sind.

edit - Ich verstehe, dass TFS alles neu ist, aber als ich es testete, hatten mehrere Entwickler, die ich gefragt habe, sehr ähnliche Gefühle. Der Grund, warum ich "im Kern" sagte, war, dass ich mich daran erinnere, dass ich mir die Dateien angesehen habe, die TFS in meiner Lösung erstellt hat und die genauso aussahen wie die von VSS erstellten. Dies ist vom Standpunkt eines Entwicklers aus gesehen, der vielleicht nicht einmal etwas über die Technologie hinter VSS, TFS oder einem anderen SCM weiß. Entschuldigung für die Verwirrung.

Damals war ich mit SCCS unter XENIX beschäftigt. In Visual Studio 6 hatte VSS bei allen Fehlern und Problemen deutliche Vorteile. Ich benutze es immer noch für kleine Projekte und verwende SCCS in keiner Version mehr.

Ich kann nicht verstehen, warum alle VSS schlecht reden wollen. VSS ist nicht verteilt, und die verteilte Versionskontrolle ist

1. besser
2. ermöglicht in der Praxis eine nicht verteilte Versionskontrolle

Bitte lesen Sie dies .