nicht angemeldet
Subversion: Unbeabsichtigte Zeitreise
Moin Moin!
Nein, mein Subversion-Server hat keinen Fluxkompensator ... ;-)
Ich hatte(!) einen Server, auf dem ein Subversion-Repository lag. Davon gibt es tägliche Backups, bis zu dem Tag, an dem der Server einen Totalausfall hingelegt hat. An jenem Tag habe ich noch zwei oder drei Commits gemacht, die natürlich noch nicht im Backup sind. An den Inhalt der Platten komme ich dank propritärem Embedded-RAID-Controller mit völlig undokumentiertem Metadaten-Format nicht mehr ran, außer ich nehme richtig viel Geld in die Hand. Der alte Server ist also zu 100% Elektroschrott.
Ich habe einen neuen Server aufgebaut, das letzte Backup wieder eingespielt (und tausend Kleinigkeiten außerhalb von Subversion gerade gebogen), und habe jetzt die wunderbare Situation, dass meine Subversion-Sandbox auf meinem Arbeitsrechner dem Subversion-Repository auf dem Server einen Tag voraus ist, bzw. der Server aus seiner Sicht einen Tag in die Vergangenheit gereist ist.
Wie bekomme ich das Subversion auf dem Server auf den Stand, den ich auch in der Sandbox habe?
Server: Linux, Subversion 1.6.16
Arbeitsrecher: XP, TortoiseSVN 1.4.6
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
Für's Archiv:
Veränderte Verzeichnisstruktur auf dem Client sichern, aus dem Weg räumen, SVN update auf den veralteten Serverstand, veränderte Dateien in die frisch veraltete Sandbox kopieren, dabei ältere Versionen überschreiben, einzelne Commits manuell nachholen. Log-Informationen sind leider verloren.
Zum Glück betraf das nur zwei Dateien, weniger als erwartet.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". -
Tach!
und habe jetzt die wunderbare Situation, dass meine Subversion-Sandbox auf meinem Arbeitsrechner dem Subversion-Repository auf dem Server einen Tag voraus ist, bzw. der Server aus seiner Sicht einen Tag in die Vergangenheit gereist ist.
Was muss man sich unter der Sandbox konkret vorstellen? Ein Arbeitsverzeichnis mit ausgecheckter Version, die derzeit drei Versionen voraus ist? Reicht nicht der Einfachheit halber, ein neues Auschecken und dann ein diff mit dem Sandbox-Verzeichnis, anschließend die neue Version patchen und commiten? Oder brauchst du unbedingt die zwei Zwischenversionen? Dann könnte ich dir nicht weiter helfen als mit "Mit git wäre das nicht passiert" (was natürlich nicht für die Vergangenheit hilft).
dedlfix.
-
Moin Moin!
Was muss man sich unter der Sandbox konkret vorstellen? Ein Arbeitsverzeichnis mit ausgecheckter Version, die derzeit drei Versionen voraus ist?
Ja.
Reicht nicht der Einfachheit halber, ein neues Auschecken und dann ein diff mit dem Sandbox-Verzeichnis, anschließend die neue Version patchen und commiten? Oder brauchst du unbedingt die zwei Zwischenversionen?
Ja. Hab's aber mittlerweile gelöst.
Dann könnte ich dir nicht weiter helfen als mit "Mit git wäre das nicht passiert" (was natürlich nicht für die Vergangenheit hilft).
Das hab ich mir auch für'n paar Sekunden gedacht. Trotzdem bleibe ich bei SVN, das eigentliche Problem war wieder einmal ein Hardware-RAID-Controller.
Die Rettung der Daten auf dem alten Server ist vor allem daran gescheitert, dass der propritäre RAID-Controller nicht ohne das tote Mainboard funktionsfähig war. Einen "normalen" RAID-Controller hätte man ja recht schmerzfrei in eine andere Maschine stecken können, die SCSI-Backplane samt Platten hätte man auch irgendwie mit Strom versorgen können.
Der neue Server besteht nun zu 100% aus Standard-Teilen (AMD FX-8150, ATX-Mainboard, 32 GByte RAM, ATX-PSU, ATX-Rackmount-Gehäuse, 6x SATA-Wechselrahmen, 4x SATA-Platte), RAID macht das Linux in Software. Die paar CPU-Zyklen extra hat die neue CPU locker übrig. Vor allem aber kann ich beim nächsten Ausfall stumpf Standard-Ersatzteile kaufen oder die Platten provisorisch an eine andere Linux-Maschine hängen, um an die Daten auf den Platten zu kommen.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Tach!
"Mit git wäre das nicht passiert"
Das hab ich mir auch für'n paar Sekunden gedacht. Trotzdem bleibe ich bei SVN, das eigentliche Problem war wieder einmal ein Hardware-RAID-Controller.Ja, stimmt schon, aber nachdem ich mir Git angesehen und erste Erfahrungen damit gemacht hatte, kann ich ein Bleiben bei SVN nur noch mit Konservativismus begründen (oder mit dem Bauern, der etwas nicht isst, nur weil er es nicht kennt). Sei es drum. Ich will dich jetzt nicht (unbedingt) überzeugen, aber ein paar mehr Worte, warum Git hier im Vorteil gewesen wäre, werde ich doch noch verlieren.
Bei SVN ist man auf Gedeih und Verderb auf das zentrale Repository angewiesen. Ist es nicht erreichbar, kann man nichts weiter machen, als in seinem derzeitigen Stand Änderungen vorzunehmen. Man kann dazu weder einen neuen Branch eröffnen, um die Entwicklung der Hauptlinie nicht zu beeinflussen, noch kann man aus seinen Zwischenschritten in ein Commit erstellen. Wenn das zentrale Repo dann wieder verfügbar ist, kann man nur einen "Monster"-Commit hinlegen oder man hätte während seiner Arbeit für die Zwischenstände Patches erstellen müssen, die man dann nachträglich Schritt für Schritt anwendet und dabei die Versionen einzeln eincheckt.
Die dezentrale Struktur von Git ist hier deutlich im Vorteil. Man kann alles lokal machen und dann in einem Zug das zentrale Repo updaten. Und "das zentrale Repo" ist auch nicht richtig ausgedrückt, denn man kann beliebig viele Remote-Repositorys anbinden. Wenn ein Remote-Repo ausfällt, kann man es recht einfach wieder aus jedem aktuellen lokalen Clone wiederherstellen. Aus veralteten Backups erstellte Repos stellen ebenfalls keine Hürde dar. Das Delta kann man ebenfalls aus einem lokalen Clone ausgleichen.
Neulich hatte ich das Bedürfnis, ein fremdes Projekt in meiner eigenen Anwendung zu verwenden, aber nicht genauso, wie es der Autor erschaffen hatte, sondern ein paar Änderungen einzubauen. Diese waren nicht für die Öffentlichkeit nützlich/vorgesehen. Aber ich wollte auch Änderungen des Projekts übernehmen können. Das heißt, ich konnte nicht einfach nur eine Kopie erstellen und mit der arbeiten. Dann hätte ich alle Änderungen händisch rübertransportieren müssen. Eine Anbindung an das Projekt und die Möglichekkeit, eigene Änderungen zu pflegen, wäre also sehr hilfreich. Dummerweise war das Projekt ein mit SVN gepflegtes Projekt und SVN half mir bei meinem Vorhaben nicht. Um einen Branch zu erstellen, hätte ich im zentralen Repository schreiben können müssen. Der wäre dann aber auch nicht mehr rein privat gewesen. Mit Git wäre das kein Problem. Man klone das zentrale Projekt, und branche und commite dann privat nach Herzenslust. Gelegentlich fetche man die zentralen Änderungen in den Hauptzweig und merge sie in den privaten. Gitseidank (scnr) war das konkrete Problem ebenfalls einfach zu lösen. Git kann auch SVN-Projekte clonen. Dann kann man privat arbeiten und gelegentlich mal fetchen und mergen. Und das heißt auch, dass man problemlos von SVN auf Git umsteigen kann: einfach einbinden.
Von SVN kommend ist die Einarbeitungszeit gering. Clone (Checkout), Fetch/Pull (Update) und Commit kennt man, geht nicht viel anders. Branchen und Mergen muss man vielleicht erst ein paar mal üben, weil man das bei SVN nicht so häufig macht. Aber bei Git geht das so einfach und schmerzlos, dass man das viel öfter einsetzen kann. Selbst wenn man sich vertan hat oder das neue Feature nur ein ganz kleines ist: kein Problem, Branch löschen geht ebenso einfach. Als 08/15-Anwender hab ich noch nichts gefunden, wo Git mir Nachteile gebracht hätte. Ein Umsteigen lohnt sich in der Regel. Zumindest schadet es nicht auf den ersten Blick. Der Geschmack kommt dann beim Essen.
dedlfix.
-
Moin Moin!
"Mit git wäre das nicht passiert"
Das hab ich mir auch für'n paar Sekunden gedacht. Trotzdem bleibe ich bei SVN, das eigentliche Problem war wieder einmal ein Hardware-RAID-Controller.Ja, stimmt schon, aber nachdem ich mir Git angesehen und erste Erfahrungen damit gemacht hatte, kann ich ein Bleiben bei SVN nur noch mit Konservativismus begründen (oder mit dem Bauern, der etwas nicht isst, nur weil er es nicht kennt).
Sei es drum. Ich will dich jetzt nicht (unbedingt) überzeugen, aber ein paar mehr Worte, warum Git hier im Vorteil gewesen wäre, werde ich doch noch verlieren.
[Schneid ich jetzt mal raus, sonst wird das Posting zu lang. "Fachlich hilfreich" mit Sternchen hast Du ja schon bekommen, und zu recht!]
Es gibt eine noch viel einfachere Begründung für SVN:
1. Ich kenne SVN.
2. Ich habe keine Zeit, mich in git einzuarbeiten.
3. Der Zentralismus von SVN ist Teil des Backup-Konzepts.Zu 2: Neben dem Tagesgeschäft liegen mindestens zwei Projekte für drei bis vier Leute für die nächsten paar Jahre auf meinem Tisch. Außer mir ist schlicht und ergreifend kein anderer da, der diese Themen bearbeiten kann. Und nein, ich habe nicht darum gebeten, mir diese Projekte zu geben! EDV-Leitung gibt's bei meinem Arbeitgeber nur auf dem Papier. Andere Geschichte.
Zu 3: Ich arbeite nach dem Motto "commit early, commit often", so dass ich auf dem Arbeitsrechner dem Repository auf dem Server immer höchstens einen logischen Schritt voraus bin. So habe ich immer eine saubere Source-Version im HEAD, und die wird im Laufe der Nacht auf dem Server gesichert. Vom Arbeitsrechner selbst gibt es kein Backup, weil der leicht wiederhergestellt werden kann (OS installieren, Browser installieren, Editor installieren, SVN installieren). Die Testumgebung liegt in einer VM auf dem Server und wird regelmäßig nachts mit gesichert.
Ich arbeite ja nicht erst seit gestern so, sondern schon länger, als man mir für mein Hobby Geld bezahlt. Dieses eine Mal habe ich mich nicht an eine meiner eigenen Regeln gehalten, die lautet: Kein Hardware-RAID!
Meine Entwicklungsserver waren - wenigstens anfänglich - immer irgendwelche geschnorrten oder ausgemusterten Maschinen, teilweise alte Desktops, teilweise alte Server, die ich mit zusammengesammelten Teilen so weit wie möglich aufgemotzt habe, immer nach dem gleichen Prinzip: Software-RAID, externe Platte für ein rsync-Hardlink-Backup. Und das hat immer funktioniert, weil dieses Setup sehr unanfällig für Hardware-Schäden ist. Wenn der Server tatsächlich kaputt geht, steckt man die Platten stumpf in einen anderen. Plattenausfäle deckt das RAID ab, und kaputte Controller stören dank Software-RAID ebenfalls nicht. Und im blödsten aller Fälle (nämlich genau diesem) hat man die externe Platte mit dem Stand von gestern.
Bei diesem Job habe ich mich von der Hardware blenden lassen. Der Server (große Marke) ist gebaut wie ein Panzer, wenn man den versehentlich fallen läßt, fällt der ohne eine Schramme bis zum Fundament durch alle Zwischendecken. Fast alles ist redundant ausgelegt, keine Elko-Pest, alles extrem sauber und ziemlich durchdacht aufgebaut. Ich habe schlicht und ergreifend übersehen, dass erstens der RAID-Controller nicht in andere Maschinen paßt und zweitens alle Ersatzteile mindestens mit Gold aufgewogen werden, wenn man nicht sogar seine Erst- und Zweitgeborenen verpfänden muß.
Und wie immer, wenn Murphy zuschlägt, schlägt er an der schwächsten Stelle zu. Das Mainboard ist nicht redundant, der RAID-Controller paßt nur zu diesem Mainboard, und die Daten lagen auf einem RAID-5 verteilt über vier Platten.
Platten aus einem RAID-1 lassen sich bei diesem Controller (zufällig?) direkt an anderen Rechnern lesen, der speichert bei einem RAID-1 die Meta-Daten offensichtlich in den letzten paar Sektoren der Platte, der Rest ist mit dem identsch, was das Betriebssystem als RAID-Verbund sieht.
RAID-5 ist bei dieser Controller-Generation nur mit exakt diesem Controller-Typ lesbar. DDF, mit dem man notfalls auch mit Linux-Bordmitteln Platten aus einem Hardware-RAID-Verbund auslesen kann, gibt's erst bei der nachfolgenden Controller-Generation, die natürlich NICHT in den Server paßt.
Hätte ich mich an meine eigene Regel gehalten, hätte ich jetzt 6 SCA-Platten, von denen zwei ein RAID-1 mit dem Betriebssystem und vier ein RAID-5 mit den Daten bilden. Mit sechs SCA-zu-SCSI-Adaptern bekäme ich die sechs Platten problemlos mit jedem beliebigen SCSI-Controller auf jedem beliebigen Mainboard zum Laufen, so lange Linux nur einen Treiber für den SCSI-Controller hat. Linux könnte problemlos alle Daten vom RAID-5 irgendwo anders hin kopieren oder notfalls auf einer völlig anders aufgebauten Ersatzmaschine mit den Original-Platten weiter laufen.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Tach!
- Ich habe keine Zeit, mich in git einzuarbeiten.
Was wäre nun besser gewesen? Doch mal die Stunde in Git investiert zu haben oder Zeit in die Reparatur eines nicht mehr ganz so guten Systems stecken zu müssen, wenn es einem grad gar nicht passt. Und laut Murphy passiert ja immer genau dann etwas.
dedlfix.
-
Moin Moin!
- Ich habe keine Zeit, mich in git einzuarbeiten.
Was wäre nun besser gewesen?
Wie ich schon schrieb: Nicht auf Hardware-RAID verlassen.
Doch mal die Stunde in Git investiert zu haben oder Zeit in die Reparatur eines nicht mehr ganz so guten Systems stecken zu müssen, wenn es einem grad gar nicht passt. Und laut Murphy passiert ja immer genau dann etwas.
Wie gesagt, git paßt nicht in das Backup-Konzept, außer ich verkrüpple es bis auf SVN-Niveau. Und dann kann ich auch gleich SVN benutzen.
Was den Zeitfaktor angeht: Es hat fast 14 Tage gedauert, das Thema mit allen Entscheidungsträgern auszudiskutieren und ein passendes, leistungsfähiges Ersatz-System in Einzelteilen bestellen zu dürfen, dann hat der Einkauf noch eine Woche still und leise auf der Bestellung gehockt, weil sie nicht wußten, auf welche Kostenstelle das gebucht werden sollte. Nachfragen wäre natürlich zu einfach gewesen. Als die Teile dann endlich kamen, war ich längst im lang geplanten Urlaub, und unmittelbar nach dem Urlaub mußte ich noch fast eine Woche lang auf eine Dienstreise, die man mit etwas Organisation im Vorfeld auch mit ein oder zwei Tagen ausgekommen wäre. So ist der Server fast zwei Monate nicht verfügbar gewesen.
Ja, das klingt völlig unglaublich. So tickt der Laden aber nun einmal.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Tach!
Wie gesagt, git paßt nicht in das Backup-Konzept, außer ich verkrüpple es bis auf SVN-Niveau. Und dann kann ich auch gleich SVN benutzen.
Kann ich nicht nachvollziehen. Man installiere gitolite auf dem Server. Zusätzlich zu den lokalen Instanzen hat man so eine Instanz, die man sichern kann. Und die lokalen sind ebenfalls gleichzeitig Sicherungen.
dedlfix.
-
-
-
-