Was passiert, wenn das Abhängigkeits-Repository auf GitHub gelöscht wird?

Ich besitze ein GitHub-Repository, A.
Repository B ist ein weiteres Open-Source-Projekt, das jemand anderem gehört.
Repository A hängt von Repository B ab (Repository B ist ein Submodul von A).

Wenn der Eigentümer von Repository B beschließt, dieses Repository zu löschen, können Benutzer mein Repository nicht mehr erfolgreich klonen / auschecken / erstellen.

Sollte ich B präventiv als Backup verwenden, falls der Eigentümer beschließt, es zu löschen? Wird dies als gefährliche Situation angesehen oder wie wird dies normalerweise bei Open-Source-Projekten gehandhabt?

open-source version-control github

Korrigieren Sie mich, wenn mir etwas fehlt, aber wenn A von B abhängt, muss jemand jedes Mal, wenn er A bauen möchte, sowohl A als auch B klonen. Selbst wenn B gelöscht wurde, hat wahrscheinlich jeder, der A verwendet, eine Kopie von B (einschließlich Verlauf) liegt auf ihrem System herum, da Git ein DVCS ist. Sie können also wahrscheinlich rückwirkend eine Gabel erstellen. Richtig? Oder ist das eine andere Art von "Abhängigkeit"?

Es ist eine normale Subrepo-Abhängigkeit. Aber im Grunde bin ich der Betreuer von A. Es ist stabil und es findet keine aktive Entwicklung statt (nur gelegentliche Korrekturen). Um meine kleine SSD sauber zu halten, behalte ich nur den Code auf GitHub. Ich bin der Meinung, dass dies eine gefährliche Situation ist, da A in Schwierigkeiten geraten wird, wenn der Besitzer von B jemals beschließt, B zu löschen, und ich keine präventive Gabel habe.

Gabeln sind frei. Wenn es Ihnen hilft, nachts zu schlafen, tun Sie es.

Wenn der Eigentümer von Repository B beschließt, dieses Repository zu löschen, können Benutzer mein Repository nicht mehr erfolgreich klonen / auschecken / erstellen.

Wenn der abhängige Code "repo B" verschwindet:

Alle Benutzer können Ihr Repo erfolgreich klonen.
Bestehende Benutzer haben wahrscheinlich eine Kopie von Repo B vor Ort und bauen problemlos weiter. Geklonte Repos werden normalerweise nicht gelöscht, wenn die Quelle gelöscht wird, es sei denn, ein Benutzer hat sich die Mühe gemacht, speziell für dieses Szenario einzurichten. Da Git ein DVCS ist, wurde es entwickelt, um sich vor solchen Dingen zu schützen.
Neue Benutzer werden nicht in der Lage zu bauen Ihre Repo , bis sie eine Kopie von Repo - B von irgendwo bekommen können. Sie würden in diesem Boot sein, da Sie kein Backup speichern.

Sollte ich B präventiv als Backup verwenden, falls der Eigentümer beschließt, es zu löschen?

Ja.

Wird dies als gefährliche Situation angesehen oder wie wird dies normalerweise bei Open-Source-Projekten gehandhabt?

Ja, dies ist eine gefährliche Situation, abhängig von der Popularität / Verteilung / den Spiegeln des abhängigen Repos und der Bedeutung Ihres Repos für Sie. Wenn es für andere wichtig ist, haben sie (hoffentlich) bereits ein Backup sowohl Ihres Repos als auch des Depos.

Beachten Sie, dass Sie es auf GitHub in Ihr Konto einbinden und nicht auf Ihre SSD klonen können, um keinen Speicherplatz zu belegen. Beachten Sie außerdem, dass diese Sicherungsoption davon abhängt, dass nichts mit den GitHub-Servern passiert oder dass Ihr Konto nicht gefährdet wird. Nur Sie können den angemessenen Redundanzgrad bestimmen.

Berücksichtigen Sie die Menge an Code, auf die Sie sich verlassen, seine Beliebtheit, die Schwierigkeit, ihn zu reproduzieren, und die Kosten für die zuverlässige Speicherung. Sichern Sie diese Risikobewertung entsprechend.

Da die Kosten ein Faktor in Ihrer Situation zu sein scheinen, da Sie nicht mehr für eine größere SSD ausgeben möchten, finden Sie hier eine Liste günstiger Sicherungsoptionen:

Gabel es natürlich auf GitHub, da es völlig kostenlos ist. GitHub verwendet die Deduplizierung, sodass die Kosten für sie äußerst gering sind.
Lokale (kostenlose), alte rotierende Festplatten oder USB-Flash-Laufwerke. Möglicherweise zahlen Sie bereits für ein kostenloses Cloud-Backup über Ihren ISP oder Mobilfunkanbieter.
Remote (kostenlos), viele kostenlose Cloud-Backup-Optionen oder fragen Sie einen Freund.
Kaufen Sie aus der Ferne ($) einen Usenet-Tarif pro GB und laden Sie ihn in das Usenet hoch (~ 25 GB für 10 USD).

— Adam
quelle