Wir migrieren von Clearcase zu einem anderen VCS (wahrscheinlich entweder SVN oder Mercurial). Für Unternehmen, die diesen Übergang gemacht haben, welche Faktoren haben sie bei der Auswahl eines anderen VCS-Tools für wichtig erachtet, und welche Praktiken haben sie gefunden, die den Übergang erleichtert haben?
SVN und Mercurial sind beide gute SCM. Viele Opensource-Projekte verwenden sie. Wenn sich Ihre Wahl auf diese beiden beschränkt, dann müssen Sie und Ihr Team Folgendes beachten:
Wie wollen Sie die Commits und Verzweigungen machen? Verteilt oder rein zentralisiert? Dies hängt auch mit der Unternehmensrichtlinie zusammen. Gehen Sie mit SVN, wenn Sie möchten, dass alles zentralisiert wird. Aber das bedeutet nicht, dass Sie kein zentrales Repository mit Mercurial haben können. Es ist sehr vorteilhaft, wenn Ihr Team DVCS wie Mercurial wählt, weil:
Abgesehen davon sind beide wirklich gut, denn beide haben gute (genug) Leistung, gute Windows-Unterstützung ( SVN , Hg ) und gute Dokumentation / Buch ( SVN , Hg ).
Ein paar hinzuzufügen sind:
Sie müssen mehrere Kriterien berücksichtigen wie:
Im Hinblick auf Migration (zu SVN oder Mercurial), es wird einfacher sein, wenn Sie ClearCase UCM verwenden, da die Baselines eine klare "Timeline" (engste Analogie zu "Revision") darstellen, die Sie zum Importieren in Ihr anderes (D) VCS verwenden können.
Wenn nicht (Base ClearCase), müssen Sie überlegen, welchen Teil des Verlaufs Sie wirklich importieren müssen.
Im Allgemeinen würde ich immer mit dem verteilten Versionskontrollsystem (DVCS) gehen. Ich habe nicht mercurial, sondern git versucht; aber die Prämisse hier ist die gleiche.
Wenn Sie ein zentralisiertes System verwenden, sind Sie an diese Struktur gebunden. Wenn Sie ein verteiltes System verwenden, sind Sie es nicht. Aber nur weil Sie es verteilen können, müssen Sie nicht. Wenn es in Ihrem Team sinnvoller ist, ein zentrales Repository zu haben, dann tun Sie es auf diese Weise.
Was Sie nicht unterschätzen sollten, ist die Macht der lokalen Niederlassungen. Die Verzweigung in einem zentralisierten System ist ziemlich umständlich, Entwickler oder Funktionszweige werden selten gemacht. Entwickler haben lieber mehrere Arbeitskopien oder behalten unsichere Änderungen in ihrer Arbeitskopie, um den Build nicht zu unterbrechen. Bei einem dezentralen System erstellt der Entwickler lokale Zweigwerke darauf. Unterbrochen von einem show-stopper-Fehler, schaltet er zurück zum Master-Zweig, behebt das Problem, schiebt die Änderungen in das zentrale Repository und wechselt zurück in seinen Feature-Zweig. Der Workflow ist extrem reibungslos.
Zusätzlich macht die verteilte Natur des Systems es zu einem robusten. Wenn der Server ausgefallen ist, ist es für die Entwickler wie gewohnt, sie können sogar ihre Änderungen untereinander austauschen.
Endlich können die Entwickler die Arbeit nach Hause nehmen, im Flugzeug, im Zug oder wo sie wollen. Sie verlieren niemals die VCS-Fähigkeit und können ordnungsgemäße Commits vornehmen.
Das Ergebnis ist, dass das Verhalten der Entwickler in Bezug auf das VCS durch die Unternehmensrichtlinien und nicht durch die Technologie definiert wird und Sie Ihre Richtlinien jederzeit ändern können.
Drittanbieter-Support Verfügt das System über einen ausgereiften SCC-Anbieter für Visual Studio? (SVN ja, Hg ist nicht reif).
Eclipse? Beide haben gute Unterstützung.
Sind Ihre Entwickler Command-Line-Kommandos? Dann können Support / Plugins von Drittanbietern kein Problem sein.
Das ist ein alter Thread, aber ich wollte etwas beitragen. IMO, SVN hat seinen Kurs ausgeführt. Nun, in Fairness, wenn Sie etwa 50 Benutzer haben und nicht viel verzweigen, dann ist es sicher nicht schlechter als CC. So alt wie CC ist und so komplex wie es ist, hat es immer noch eine Menge ausgereifte Funktionalität. Wenn Sie also ein reifer CC-Shop sind, wird SVN Ihre Anforderungen nicht erfüllen. In der Tat ist es eine gute Übung, weniger zu verzweigen und den Hauptstamm abzubauen. Also wäre eine bessere Wahl (angesichts der oben genannten Möglichkeiten) Hg. Außerdem bin ich voreingenommen gegenüber dvcs. true dvcs das ist ... und es gibt nur 2 OSS-Optionen: Hg und Git. und derzeit ein kommerzielles System, Kunststoff scm. Wenn Sie es gewohnt sind, Ihre Dateihistorie visuell darzustellen (vtree-Browser oder Komponentenbaum-Browser in CC UCM, denken Sie, dass es so genannt wurde), ist Plastik möglicherweise eine praktikablere Wahl. Wie ich gesehen habe, hat es den grafischen vtree und etwas anderes, wie den Zweigbaum-Explorer. Ich erinnere mich daran, CC zu unterstützen, wo sich viele von uns am Whiteboard abwechselten und das "Prozess" -Modell herauszogen. Kunststoff hat es eingebaut. wie auch immer, ich bin wieder voreingenommen gegenüber dvcs ... ich habe genug mit svn und cc gelitten und versucht, teure replikations-tools und mastership scripting zu verwenden. DVCs ist so einfach! Wenn Sie ein Hardnose-Linux / Unix-Entwickler sind, könnte Git eine bessere Wahl sein. Wenn mehr Fenster oder eine Mischung vorhanden sind, sehen Hg und Plastic besser aus. mehr Grafiken und Visuals mit Plastik. Ich denke Hg vermisst eine Menge der Erlaubnis und Zugriffskontrollen, die Sie mit CC gewohnt sind ... also könnte Kunststoff hier die Kante haben. hoffe das hilft und viel Glück!