Hallo zusammen, es ist Freitag, es läuft ein Backup, und ich habe Zeit, mich mit Grundsatzfragen zu beschäftigen. Für die Softwareentwicklung nutze ich immer noch SVN als Versionsverwaltung, weil es alles bietet, was ich benötige. Das meiste, was ich mache, sind Auswerte- und Konvertierungsskripte und -Programme. Die eigentlichen Quelltexte sind winzig. Insgesamt hat kaum ein Programm mehr als 5kZeilen. Was den meisten Platz einnimmt, sind die Testdaten. Die meisten davon sind Echtdaten. Bisher habe ich die Testdaten immer im Repository untergebracht, weil zum Gegentesten alter Versionsstände auch die alten Testdaten gehören. Sie fressen ja kein Brot. Außer freitags, wenn das Backup läuft. So ein 4-GB-Repo, von denen 3,9X GB Testdaten sind, dauert schon etwas zu packen. Und viele Repos dauern leider erst Recht... Also: Wie macht ihr das? Kommen bei euch Testdaten ins Repository oder werden die separat abgelegt? Wenn ja: Werden die irgendwie abgespeckt? Wenn nein: Wie haltet Ihr das Projekt-Repository und die anderen Daten konsistent?
Kann man mit SVN auch Repos verlinken bzw wie bei git als externe subdir einbinden? So würde ich es mit git machen.
J. S. schrieb: > Kann man mit SVN auch Repos verlinken bzw wie bei git als externe subdir > einbinden? Ah, Du meinst ein zweites Repo nur mit sich selten ändernden Daten (Testdaten und Co.) verlinken. Dann würde sich das zweite Repo recht selten ändern und damit das Backup beschleunigt. Das könnte klappen. J. S. schrieb: > So würde ich es mit git machen. Würdest Du oder machst Du es so?
Wir (4ma) ist schon länger von SVN nach git umgezogen, beides habe ich nicht administriert. In git haben einige Kollegen dicke Blobs abgelegt, da kriegt der Admin immer einen dicken Hals weil das git ziemlich lahmlegt wenn diese Blobs auf Änderung überprüft. Ich müsste mal nachfragen wie es jetzt gehandhabt wird, git submodule sind schon komplizierter. Und svn ist wie gesagt schon lange raus hier.
Verstehe, ihr seid also (grob) auf dem gleichen Stand wie ich, nur eben auf Git: Die Repos sind riesig, und irgendwie ist das lästig, und irgendwie kann man aber auch damit leben.
Ja, ich habe auch eine private gitlab Instanz im Proxmox für eigenes Zeug. Da kommt man kaum mit den Updates hinterher, vielleicht gibt es da auch schon bessere Strategien. Würde mich auch interessieren. Es gibt bei uns noch ein NAS wo große Mengen Test/Bilddaten liegen, aber das ist nicht direkt mit Anwendungen verknüpft. Für automatisierte Tests willst du sicherlich definierte Szenarien haben wollen.
Walter T. schrieb: > Wie macht ihr das? Kommen bei euch Testdaten ins Repository oder werden > die separat abgelegt? Da kommt alles ins Repo rein. Was würdest du gewinnen, wenn du die Testdaten separat ablegst, ausser noch mehr Chaos? Hier wird auch SVN verwendet, ist einfacher als git. SVN speichert was ich weiss sowieso nur Änderungen ab, und die Daten werden komprimiert.
Walter T. schrieb: > Außer freitags, wenn das Backup läuft. So ein 4-GB-Repo, von denen 3,9X > GB Testdaten sind, dauert schon etwas zu packen. Und viele Repos dauern > leider erst Recht... Ich habe ein tägliches Backup, mit rsync & hardlinks. Ein Rasberry PI verbindet sich per ssh+rsync auf den Server. Ein paar Stunden dauert das schon, sind hunterte GB, aber so schlimm ist das ganze eigentlich nicht. Ist ja inkrementell, und ich merke davon ja nichts.
Daniel A. schrieb: > Ist ja inkrementell, und ich merke davon ja nichts. Udo K. schrieb: > Was würdest du gewinnen, wenn du die > Testdaten separat ablegst, Ich merke davon schon etwas, weil ich keinen Server betreibe. Für alles, was Software angeht, bin ich ein 1-Mann-Betrieb. Die Repos liegen bei mir lokal auf einem Büro-PC. Ausnahme ist nur ein einziges Repo, das auf einem Raspberry Pi liegt und dazu dient, CAM-Daten mit Maschinensteuerungen auszutauschen. Obwohl der PC acht virtuelle Kerne besitzt, läuft beim Backup alles extrem zäh, vor allem während des SVN-Dumps vom Raspberry PI, aber eben auch beim Packen der Repository-Hotcopies.
Walter T. schrieb: > Kommen bei euch Testdaten ins Repository Ja, aber nicht jedesmal komplett kopiert, sondern nur inkremental die veränderten/hinzugefügten Tests. Nach jedem erfolgreichen build wird alles eingecheckt, von Sourcen über build Skripte bis Testdaten und Testergebnissen und Kompilaten mit Setup. Es ist jederzeit möglich, das build mit Tests in ein eigenes Verzeichnis auszuchecken und dort die damals gebuildete Version laufen zu lassen. Ja, wir haben auch die EXEs eingecheckt, obwohl die viel Platz kosten weil die incremental nicht komprimierbar sibd, aber nachdem sich mal herausstellte, dass ein rebuild des Eingecheckten nicht zum selben Ergebnis führte weil Uhrzeiten und uninitialisierte Speicherbereiche zu Abweichungen führten, haben wir genug Plattenplatz gekauft.
Nein. (Größere) Daten haben in Repos nichts zu suchen. Dafür gibt es Datenbanken, Sharepoints, oder auch Binary Storages wie Artifactory oder GitLab (Generic) Package Registries. Revisionierte Skripte stellen sicher, dass diese Daten on demand heruntergeladen werden.
ich würde mal den Ansatz versuchen: 0. Testdaten abspecken, hunderte identische (korrekte) Tests braucht man eher selten. Hauptaugenmerk auf Grenz- und Sonderfälle 1. (test)Daten in ein eigenes Repository packen. Das ändert sich nur, wenn sich aus irgendeinem Grund die Testdaten ändern. 2. Symlink auf das Testdaten-Repository. Der Symlink wird versioniert aber alles unterhalb wird aus der Versionierung ausgeschlossen SVN ist ziemlich lange her aber es sollte eigentlihc funktionieren. Würde es auch mit git so versuchen, bevor ich mir git submodule (wieder) antue probiere ich es lieber zuerst so ;-)
Daniel F. schrieb: > Hauptaugenmerk auf Grenz- und Sonderfälle Naja, Geschwindigkeitstests mit großen Datenmengen gehören ja auch dazu.
J. S. schrieb: > Kann man mit SVN auch Repos verlinken bzw wie bei git als externe subdir > einbinden? So würde ich es mit git machen. In svn gibt es externals. Das ist flexibler als git submodules. J. S. schrieb: > In git haben einige Kollegen dicke Blobs abgelegt, da kriegt der Admin > immer einen dicken Hals weil das git ziemlich lahmlegt wenn diese Blobs > auf Änderung überprüft. Es gibt auch noch git-lfs (large file storage). Da werden große Binary-Files separat abgespeichert, und im Repo liegt nur noch der Link, so dass der git-Client die Files automatisch da runterladen kann. Man kann Filenamen-Patterns konfigurieren, die automatisch ohne weiteres Zutun im lfs landen. Das ganze ist aber wohl etwas hakelig, wenn man es über ssh nutzen will.
Testdaten werden hier per script erzeugt, die Testdaten selbst werden somit nicht gesichert, bis auf ein paar kleinere Fetzen die sich nicht per script erzeugen lassen. Kommt nat. auf das Projekt an mit welchen Daten man da hantiert.
Testdaten als eigenes repo, aus dem eigentlichen Produktivprojekt als external verweisen. Dann kann man im Trunk immer die aktuellsten Testdaten nutzen, im branch eine stable-version peggen und bei jedem Tag die external-version festziehen die man braucht. ET voila. Testdaten per Skript erzeugen wenn möglich - Grad für Loadtest oder so- ist natürlich auch ne gute Idee.
Walter T. schrieb: > Was den meisten Platz einnimmt, sind die Testdaten. Die meisten davon > sind Echtdaten. Wahnsinn. Testdaten kann man auch abkürzen mit dem bekannten "keine Nachrichten". Hinsichtlich der Echtdaten sollte man schauen, ob nicht Platzhalter drin sind, die sich gut speichern, verkleinern oder verwalten lassen.
Wie viel Umbau darf es denn sein? Im Idealfall solltest du deine Testdaten von dem Code trennen, Vorschläge wie das gehen kann wurde ja schon gemacht. Vielleicht solltest du außerdem überlegen, ob es sinnvoll für dich ist von Subversion auf git zu konvertieren. Ein Vorteil in deinem Backup Szenario ist, dass git dezentral ist. Das Backup vom git kann daher einfach n-weitere (bare) Repositorys sein, welche irgendwo liegen. Diese Repositorys pullen dann einfach alle x-Stunden die letzten Änderungen. Das sollte schnell gehen, da nur das diff der letzten Änderung übertragen wird. Sollte es doch mal zum Recovery kommen, alle Git Instanzen sind gleichberechtigt, die Entwickler müssen sich nur einigen welche Instanz das Haupt Repository ist, im Worstcase ändern sie einfach nur die URL des Remote und können gleich weiter arbeiten.
Die Frage lautet nicht: "Was sollte ich machen?" Die Frage war: "Wie macht ihr das?", implizierend, dass ein Projekt mit Testdaten vorhanden ist. Wer das Problem nicht hat, braucht sich auch nicht den Kopf zu zerbrechen, eine Lösung zu finden. Hier noch einmal die ursprüngliche Frage: Walter T. schrieb: > Wie macht ihr das? Kommen bei euch Testdaten ins Repository oder werden > die separat abgelegt? > > Wenn ja: Werden die irgendwie abgespeckt? > > Wenn nein: Wie haltet Ihr das Projekt-Repository und die anderen Daten > konsistent?
:
Bearbeitet durch User
Auch wenn man es nicht soll - ich checke regelmäßig 1-2GB an PDFs ein, weil es sich so leichter replizieren lässt. Da sind aktuell so 250gb drinnen (+ scriptset, Word Files,...). Auf aktueller Hardware ist der overhead mehr als vertretbar. Sobald git weiß welcher stand lokal herrscht, geht das eigentliche Update ziemlich schnell. Einchecken dagegen dauert etwas ... Bei einigen GB sind das aber nur einige, wenige minuten. Das Bottleneck ist eigentlich immer das 1gbit LAN. Bis auf den eigentlichen Transfer sehe ich keinen Unterschied zwischen lokalem und remote zugriff über Handy und von (wireguard). Bei rsync muss Datei für Datei verglichen werden. Das sehr ich als mögliche schwachstelle. Git hat dazu z.B. seine Metadaten im Hintergrund. Am nas läuft gitea unter truenas auf einem 4000er i3 mit 32 oder 64gb RAM Clients sind ab i5 der 8000er Generation mit zumindest 32gb RAM 73
:
Bearbeitet durch User
Hans W. schrieb: > Bei rsync muss Datei für Datei verglichen werden. Das sehr ich als > mögliche schwachstelle. Bei rsync (wenn man es richtig anwendet), bilden beide Seiten jeweils Checksummen und haben dafür die volle lokale SATA/NVMe-Bandbreite zur Verfügung. Über das Bottleneck Netzwerk gehen nur die Prüfsummen zum vergleichen, eigentliche Daten nur wenn Unterschiede gefunden wurden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.