Versionsverwaltung mit SQL Datenbank
-
Hi,
ich schreibe grade ein Programm zur Verwaltung von versionierten Datensätzen. Diese werden aktuell in einer SQL Datenbank gespeichert. Für die Versionierung wird zu jedem Eintrag eine stets aufsteigende Versionsnummer gespeichert (vgl. SVN). Auf einen Versionsstand greife ich über diese Versionsnummer zu - es werden die Daten mit der höchsten Versionsnummer bis zu maximal der ausgewählten geladen.
Jetzt kommt hinzu, dass ich auch Branchen möchte, d.h. Änderungen an einer älteren Version durchführen, die nicht in die neueren Versionen einfließen.
Dazu fehlt mir aktuell irgendwie ein sinnvolles Konzept. Habt ihr irgendwelche Ideen?
-
Für's Branchen alles kopieren, oder mehrteilige Versionsnummern verwenden.
(1.1 brancht von 1 weg, 1.2 überschreibt 1.1 als neue Version, 1.2.1 brancht von 1.2 weg etc.)
-
Bei branches und tags würde ich nichts kopieren, da die Revisionsstände sich nie ändern (sollten). D. h. du bräuchtest eine extra branches-Tabelle mit lediglich den Referenzen zur aktuellen Revision der Datei. Erst beim Ändern der branches-Dateien müsstest du die Änderungen separat lagern.
-
Ich hab mir überlegt, ich könnte ja auch eine Branchspalte einfügen, in die ich die Branch-Nummer eintrage. Über eine zusätzliche Branch-Tabelle könnte ich dieser Nummer einen Namen und eine Base Version zuordnen...
-
Die "Branch-Nummer" hast du doch schon, dein Primary Key.
-
shadow schrieb:
Bei branches und tags würde ich nichts kopieren, da die Revisionsstände sich nie ändern (sollten). D. h. du bräuchtest eine extra branches-Tabelle mit lediglich den Referenzen zur aktuellen Revision der Datei. Erst beim Ändern der branches-Dateien müsstest du die Änderungen separat lagern.
Wenn es BLOBs gibt, dann werden diese natürlich nicht kopiert. Die Datensätze muss man, wenn man es einfach machen will, trotzdem kopieren. (Da stünden bei einer klassischen Versionsverwaltung die Filenamen, Attribute etc. drinnen + ein Verweis auf den BLOB.)
Das kann auch einigermassen viel werden. Unsere Projekt-Branches haben >> 100K Files. Und Release-Branches und Tags haben wir im SVN auch mehrere 100. So eine Datenbank würde dann schon reichlich gross.Team-Foundation-Server macht es allerdings so, auch ein Grund warum empfholen wird nicht zu viele Projekte im gleichen Repository abzulegen.
SVN macht es dagegen anders, dafür aber auch sehr kompliziert.
Die Variante mit den Mehrteiligen Versionsnummern ist ein Kompromiss: man kann nicht beliebig oft einen Branch von einem anderen Branch machen (weil die Nummer dann irgendwann zu lange wird), dafür ist das System halbwegs einfach.
