Unterstützen verteilte Versionskontrollsysteme schlechte Backup-Gewohnheiten?

Question

In einem DVCS hat jeder Entwickler ein gesamtes Repository auf seiner Arbeitsstation, auf dem sie alle ihre Änderungen festschreiben 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 ist dies ein Nebeneffekt, der anfälliger für das Backup ist. In einem traditionellen zentralisierten System wissen sowohl Sie als Entwickler als auch die Verantwortlichen, dass, wenn Sie etwas festlegen, es auf einem zentralen Server gespeichert wird, der über anständige Backup-Lösungen verfügt.

Aber mit einem DVCS scheint es, Sie müssen nur Ihre Arbeit auf einen Server schieben, 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 diese netten SVN-Commit-E-Mails sehen kann, um eine ungefähre Vorstellung davon zu haben, was in der Code-Basis passiert?

Ist irgendetwas davon ein echtes Problem?

Answer 1

ich kann Verstehen Sie Ihre Bedenken, dass Entwickler Backups vergessen, sobald ihr lokales Diff verschwunden ist (weil sie lokal committed haben) und sie nicht mehr mit reichlicher 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 Namespaced-Zweigen 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 so aggressiv einen 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 das gleiche Risiko zu geringeren Kosten.

Answer 2

Eine lokale Kopie des Repositorys könnte schlechte Backup-Gewohnheiten fördern, wenn man locker ist. Ihr Master-Repository sollte jedoch gesichert werden.

Die "lokale Kopie des gesamten Repository" ist viel wichtiger als eine Sicherung. Es reduziert die Latenzzeit bei der Untersuchung des Verlaufs der Codebasis - z. B. bei der Gegenüberstellung mit der neuesten Version - von einer Netzwerk-Rundreise zu einer Reise zu Ihrer lokalen 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 Zwischenrepository haben, das halb gebackene Features mit den Commit-Mails oder was auch immer zulässt.

Edit: In Bezug auf John Kommentar über einen lang andauernden Versuch verloren, weil sie nicht bereit waren, an die Master-Repo zu begehen: Arbeit in einem separaten Zweig und regelmäßig Ihre Änderungen an den Master schieben. Sie haben immer noch alle Vorteile, gegen ein lokales Repository zu arbeiten (hauptsächlich für mich, sehr geringe Latenzzeiten), und ärgern Sie Ihre Kollegen immer noch nicht mit Ihrer unausgegorenen Funktion ... und Sie können Ihre Änderungen immer noch von Ihrem Computer aus speichern ein Ort, an dem Ihr Administrator das Repository ordnungsgemäß sichern kann.

Answer 3

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.

Answer 4

In den meisten Orten stelle ich mir vor, dass es wahrscheinlich immer noch ein "zentrales" Repository gibt, aus dem Builds gemacht und getestet werden. Wenn Sie Ihren Code im Build haben wollen, muss er zentral gepackt werden.

Dies ist auch ein Management-Problem - sagen Sie Ihrem Team - Push regelmäßig (mindestens täglich), so dass Ihr Code gesichert wird. Wenn es nicht gemacht wird, dann hole den großen Stock raus.

Ich würde auch beachten, dass, wenn Sie auf der Suche auf die Commits angewiesen sind, um zu sehen, was Ihre Mitarbeiter tun, werden Sie wahrscheinlich einige größere Probleme, die Sie bei Adressierung aussehen könnte ...