In einem DVCS hat jeder Entwickler ein gesamtes Repository auf seiner Workstation, auf das sie alle ihre Änderungen übertragen können. Dann können sie ihr Repo mit dem eines anderen zusammenführen oder es klonen oder was auch immer (wie ich es verstehe, bin ich kein DVCS-Benutzer).
Für mich bedeutet das einen Nebeneffekt, dass ich anfälliger dafür bin, Backups zu vergessen. In einem traditionellen zentralisierten System wissen sowohl Sie als Entwickler als auch die Verantwortlichen, dass, wenn Sie etwas begehen, es auf einem zentralen Server gespeichert wird, der über anständige Backup-Lösungen verfügt.
Aber mit einem DVCS scheint es, dass Sie Ihre Arbeit nur auf einen Server verlagern müssen, wenn Sie es teilen möchten. Es ist alles sehr gut, dass Sie das Repo lokal haben, so dass Sie einen Monat lang an Ihrem Feature-Zweig arbeiten können, ohne jemanden zu belästigen, aber es bedeutet (denke ich), dass das Einchecken Ihres Codes in das Repo nicht genug ist schiebt auf einen gesicherten Server.
Es bedeutet auch, dass ein Teamleiter nicht all die netten SVN-Commit-E-Mails sehen kann, um eine grobe Vorstellung davon zu haben, was in der Code-Basis vor sich geht?
Ist das wirklich ein Problem?
Ich kann Ihre Bedenken verstehen, dass Entwickler Backups vergessen, sobald ihr lokaler Unterschied verschwunden ist (weil sie lokal committen), und sie nicht mehr mit reichlich Ausgabe belästigen. Ich denke, die Lösung kann in besseren Werkzeugen, Moar-Werkzeugen liegen! Sie könnten einen Cron-Job in jeder Dev-Box einrichten, der jedes letzte erreichbare Objekt in seinem Repository zum zentralen Repo schiebt und sie im zentralen (gesicherten) Repo mit Namespace-Verzweigungen beschriftet. Ich denke, dass "git push" dies tun kann, wenn man die korrekte Refspec befolgt. Dann beeinflusst alles, was Sie nicht tun, den Zustand Ihrer öffentlichen Zweige.
Aber brauchen Sie wirklich einen so aggressiven Backup-Prozess wie zuvor, als der Repo nur an einem Ort existierte? Mit einem DVCS benötigen Sie eine weitaus höhere Kategorie von Katastrophen, um Ihren gesamten Code zu verlieren. Sie brauchen jetzt einen Asteroiden oder eine Bombe, die Ihr Büro (und alle Ihre externen Teammitglieder) trifft, anstatt nur eine Festplatte oder einen RAID-Controller schlecht zu machen. Beachte, ich befürworte keine Schlamperei; Ich befürworte ein gleiches Risiko zu geringeren Kosten.
Ich glaube nicht, dass Sie einen Automatismus haben. Verteilte oder zentralisierte VCS können mit Backup kombiniert werden (oder nicht). Es ist alles eine Frage der Disziplin im Team.
Gleiches gilt für Commit-E-Mails. Wenn das Team die Disziplin hat, regelmäßig Änderungen an den richtigen Repositories vorzunehmen, können Sie auch eine funktionierende Commit-Mailingliste haben.
Schlechte Angewohnheiten können auch in einem Team mit zentralisiertem VCS wachsen. Du musst immer schlechte Gewohnheiten bekämpfen.
An den meisten Stellen stelle ich mir vor, dass es wahrscheinlich immer noch ein "zentrales" Repository gibt, aus dem Builds gemacht und getestet werden. Wenn du deinen Code im Build haben willst, muss er zentral verschoben werden.
Dies ist auch ein Management-Problem - sagen Sie Ihrem Team - drücken Sie regelmäßig (mindestens täglich), damit Ihr Code gesichert wird. Wenn es nicht gemacht wird, dann hole den großen Stock heraus.
Ich würde auch bemerken, dass wenn Sie sich auf die Commits verlassen, um zu sehen, was Ihre Mitarbeiter tun, haben Sie wahrscheinlich ein paar größere Probleme, die Sie möglicherweise ansprechen ...
Wenn Sie eine lokale Kopie des Repositorys haben, könnte dies zu schlechten Backup-Gewohnheiten führen, wenn Sie keine Lust haben. Ihr Master-Repository sollte jedoch gesichert werden.
Die "lokale Kopie des gesamten Repositorys" ist viel wichtiger als eine Sicherung. Es reduziert die Latenzzeit bei der Untersuchung des Verlaufs der Codebasis - z. B. gegen die neueste Version - von einer Netzwerkrundreise zu einer Reise auf Ihre lokale Festplatte.
Das hört sich gar nicht so schlimm an, wenn sich Ihr Haupt-Repository auf Ihrem Gigabit-LAN befindet. Wenn Sie ein Telearbeiter sind und das Repository über ein VPN gut 600+ ms entfernt ist, macht es einen Unterschied.
Ich habe mich nie damit befasst, aber ich bin mir sicher, dass sowohl Mercurial als auch Git Post-Commit-Hooks unterstützen, so dass Sie Commit-Mails für den Teamleiter einrichten können. Dann könnte jeder Entwickler sein Repository entsprechend einrichten oder ein Zwischen-Repository haben, das halb gebackene Features mit den Commit-Mails oder was auch immer zulässt.
Bearbeiten: In Bezug auf Johns Kommentar, dass ein lang andauerndes Experiment verloren gegangen ist, weil es nicht bereit war, das Master-Repo zu übernehmen: Arbeiten Sie in einem separaten Zweig und pushen Sie Ihre Änderungen regelmäßig an den Master. Sie haben immer noch die Vorteile, gegen ein lokales Repository zu arbeiten (hauptsächlich für mich, sehr niedrige Latenzzeiten), und ärgern Sie Ihre Kollegen immer noch nicht mit Ihrer unausgegorenen Funktion ... und Sie können Ihre Änderungen immer noch von Ihrem Rechner aus speichern ein Ort, an dem Ihr Administrator das Repository ordnungsgemäß sichern kann.
Tags und Links version-control dvcs