Laden...

Versionierungssystem als File System

Erstellt von Timur Zanagar vor 18 Jahren Letzter Beitrag vor 18 Jahren 3.875 Views
Timur Zanagar Themenstarter:in
1.457 Beiträge seit 2004
vor 18 Jahren
Versionierungssystem als File System

Hallo leute,

ich weiß der Titel hört sich etwas schräg an aber anders konnte ich es in ein paar Worten nicht zusammenfassen.

Es geht um folgendes. Ich habe eine Datenbank, die unterschiedliche Dokumente verwaltet und möchte nun bei jeder Änderung die neue Version und die älteren Versionen haben.

Nun möchte ich aber das Rad nicht neu erfinden wenn möglich sondern das ganze in meine Anwendung einbauen. Es sollte auch möglich sein für bestimmte bereiche eine Art Share einzurichten, um über den File Explorer draufzuzugreifen.

VIelen Dank schon mal im Voraus.

S
8.746 Beiträge seit 2005
vor 18 Jahren

Ich kenne zumindest von einem KonfigManagement-System eine solche Funktion: StarTeam von Borland. Da gibt es ein Add-On-Produkt namens StarDesk, welche genau das macht.

Ist aber nicht ganz billig (1000€ pro User). Ob es da Freeware gibt ist mir nicht bekannt.

Dann gibt es da noch den Sharepoint-Server von MS. Der kann sowas wohl auch:

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/sharepoint/fsdoclib.mspx

A
41 Beiträge seit 2003
vor 18 Jahren

Nimm doch CVS oder subversion und hol dir den diff der letzten Datei.
damit hast du dann beide Versionen - oder eben nur die Unterschiede oder was auch immer - wie du es dann anzeigst kannst du dir ja aussuchen...

(oder habe ich die Frage falsch verstanden und du willst ein fertiges forms Projekt welches du dann in deine Anwendung einbindest ?)

gruß Andy

Timur Zanagar Themenstarter:in
1.457 Beiträge seit 2004
vor 18 Jahren

Ich kann doch nicht einfach ein CVS oder subversion nehmen und in meine Anwendung miteinbauen wenn dies Kommerziell sein wird, oder täusch ich mich da.

M
456 Beiträge seit 2004
vor 18 Jahren

Na ja, Subversion steht unter einer BSD artigen Lizenz (siehe http://subversion.tigris.org/faq.html#collab).
Bedeutet also, dass eine Ansteuereung durch kommerzielle Software durchaus möglich ist. Zumindest hab ich nix in der Lizenz gefunden, welches das verhindern könnte. Die Bedingungen der Softwarelizenz mußt du aber trotzdem einhalten (z.B. Urheber in Dokumentation nennen, ...)

I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.

Timur Zanagar Themenstarter:in
1.457 Beiträge seit 2004
vor 18 Jahren

Wenn das so ist, dann werde ich wohl kein Problem damit haben?!

Ich werd mir die Lizenz nochmal anschauen.

S
8.746 Beiträge seit 2005
vor 18 Jahren

Allerdings hast du die Dokumente dann nicht mehr in deiner Datenbank, die werden dann von CVS oder was auch immer verwaltet...

Timur Zanagar Themenstarter:in
1.457 Beiträge seit 2004
vor 18 Jahren

Ich habe mich nun entschieden ein CVS in C# selber zu schreiben. Nicht nur um es selber zu benutzen, sondern auch die Arbeitsweise eines solchen Systems zu verstehen und zu lernen.

Da wie es aussieht solche Systeme eigentlich wie Sand am Meer gibt, würde ich gerne wissen ob es irgendwelche Bedürfnisse gibt, die andere CVS Systeme nicht haben?

Meine Vorstellung wäre, dass man über .NET / MONO eine Ansteuerung an die CVS Engine erstellen kann und aber auch die Daten an einer beliebigen Stelle abspeichern kann (egal welche Datenbank, die Struktur muss passen)!

Deswegen würde ich gerne wissen ob überhaupt ein Interesse besteht oder ob ich das ganze eigentlich umsonst entwickle???

1.549 Beiträge seit 2004
vor 18 Jahren

Rein vom bedarf würde ich sagen das keiner besteht wie du schon selbst schreibst gibt es Systeme wie Sand am Meer aber was soll’s du schreibst auch das es für dich selbst als Weiterbildung herhalten soll da ist es doch egal ob es schon mehre solche Programme gibt.
Da ist es doch sogar von Vorteil wenn es Open S Programme gibt von denen du Ideen übernehmen kannst

Wir Arbeiten eigendlich nicht wir nehmen nur das geld

Timur Zanagar Themenstarter:in
1.457 Beiträge seit 2004
vor 18 Jahren

Da gebe ich dir Recht. Werde es erstmal anfangen und das Grundsystem aufbauen. Wenn dies steht werde ich es für meine Bedürfnisse erweiteren und dann mal abwarten ob noch Resonanz kommt.

Ich bin bestimmt nicht der einzige, der für bestimmte Anwendungen / Projekte ein CVS gerne hätte.

Es gibt z.B. auch genügend ZIP Anwendungen aber meines erachtens nur ein frei verfügbare ZIP Library (von Sharpdevelop)!

Ich werde mal anfangen die Enginge zu erstellen.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo burning snow,

bitte verstehe das folgende nicht als Kritik, sondern als Warung.

Ich denke nämlich du unterschätzt den Aufwand gewaltig. Natürlich kiegt man ein Grundsystem noch relativ schnell hin. Aber so ein Grundsystem braucht eben keiner, weil es ja genug Alternativen gibt.

Wenn du besser werden willst als die bestehenden Systeme - und sei es auch nur in einem bestimmten Bereich -, explodiert m.E. der Aufwand.

Mal abgesehen von der Zuverlässigkeit. Immerhin vertraut man einem Versionsverwaltungssystem i.d.R. wichtige wenn nicht gar die wichtigsten Dokumente an. Wenn beim Ermitteln der Differenzen (die ja überlichweise gespeichert werden) und/oder dem Wiederherstellen der Originaldokumente und/oder der Synchronisierung der Zugriffe irgendwelche (minimalen) Fehler (und sei es in wenigen Spezialfällen) enthalten sind, kann es sein, dass komplette Versionsbäume unbrauchbar werden.

Daher würde ich nur ein entsprechend ausgereiftes System einsetzten.

Um diesen Reifegrad zu erreichen, musst du aber m.E. eine Community um dein System scharen (Tester, Benutzer, Patcher, Entwickler). Und dazu musst du dein System direkt gegen die etablierten System durchsetzen (womit sich die Katze in den Schwanz beißt). Das kann man sicher schaffen, aber ich bezweife, ob du diese Energie wirklich aufbringen willst. Zumal dich ja nicht mal ein konkreter Verbesserungswunsch treibt, sondern dir mögliche Verbesserungen gegenüber den bestehenden System noch unklar sind.

Wenn du die Funktionsweise verstehen willst, dann schreib dein Grundsystem, ohne den Anspruch, dass es mal einsetzbar wird. Also quasi write-only; minimaler Aufwand; nicht mal testen, sondern wegschmeißen, sobald du die Funktionsweise verstanden hast.

Ich hoffe, dir hilft diese Einschätzung.

herbivore

Timur Zanagar Themenstarter:in
1.457 Beiträge seit 2004
vor 18 Jahren

Vielen Dank für deine Einschätzung. Wobei ich gleich sagen muss dass diese Einschätzung mir vor diesem Thread schon bewusst war und ist. Deswegen ging es auch darum ob es bestehende Systeme gibt, die ich in meine Anwendung ohne Probleme integrieren kann.

Mein Wunsch ist es keinesfalls ein neues System zu entwickeln und besser wie anderen zu sein 🙂 Die Zeit habe ich nicht!

Die eigentliche Problematik ist es dass ich ein CVS in meiner Anwendung benötige um Versionen von Dokumenten / Dateien zu erstellen und diese Daten sollten in meiner Datenbank liegen.

Folgende Auswahlmöglichkeiten bestehen:

1.) Selber schreiben --> Zeitaufwand, Einarbeitung, usw, usw.
2.) Ein bestehendes System miteinbinden --> geringerer Zeitaufwand für die Integration

Ich würde gerne 2. in diesem jetzigen Stadium gerne bevorzugen, bin aber bis jetzt nicht auf einen grünen Zweig gekommen.

Desweiteren nochmal zurück zur Zuverlässigkeit eines Systems.

Auch dies ist mir bewusst, welche enorme Verantwortung ein solches System mitbringt. Es ist keine Frage was alles dahintersteckt. Egal um welche Dokumente es sich handelt. Egal ob es nun Source Code ist oder "nur" ein Word Dokument welches als Inhalt einen Vertrag hat.

Auch ist mir bewusst das so ein System nicht von heut auf morgen entsteht. Bis es eine 100%ige Engine steht, die keine Fehler in welches Situationen auch immer aufweißt, braucht es Zeit und viele Testsysteme.

Damit überhaupt jemand so eine "neue" Anwendung testet, und sein bestehendes System links liegen lässt, muss dieser in irgendeiner Art und Weise überzeugt sein.

Zuerst wurde CVS gelobt und seit einiger Zeit schwärmt jeder von Subversion.

Wenn es nicht anders geht werde ich wahrscheinlich die 1.te Variante durchführen und mir die Zeit nehmen. Was ich aber noch immer hoffe ist das ich die zweiter Variante durchführen kann.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo burning snow,

gut, dann mal zu deinem eigentlichen Problem der Speicherung in der Datenbank. Wie svenson schon sagt, hast du bei der der Verwendung eines bestehenden Systems "die Dokumente dann nicht mehr in deiner Datenbank, die werden dann von CVS oder was auch immer verwaltet".

Nehmen wir als Beipsiel RCS (ist zwar schon sehr alt, aber dafür auch sehr übersichtlich). Dort wird für jede Datei, die versioniert werden soll, eine neue Datei angelegt, das sog. Repository. Das ist eine Datei in einem bestimmten Format, welches eben für die Verwaltung mehrer Versionen in einer Datei entworfen wurde. Für alle Versionen von test.txt wird also genau eine Datei test.txt_ (=Repository) angelegt.

Wenn man die Datei text.txt mit dem Inhalt

Zeile 1
Zeile 2
Zeile 3
Zeile 4
Zeile 5

in RCS eincheckt (Version 1.1) und anschließend eine 'Zeile 1b' einfügt und 'Zeile 4' löscht und diese neue Version ebenfalls eincheckt (Version 1.2), dann erhält man folgendes Repository:

head  1.2;
access;
symbols;
locks; strict;
comment  @# @;


1.2
date  2005.07.10.08.43.48; author anonymous; state Exp;
branches;
next  1.1;

1.1
date  2005.07.10.08.39.22; author anonymous; state Exp;
branches;
next  ;


desc
@@


1.2
log
@*** empty log message ***
@
text
@Zeile 1
Zeile 1b
Zeile 2
Zeile 3
Zeile 5
@


1.1
log
@Initial revision
@
text
@d2 1
a4 1
Zeile 4
@

Du siehst, dass die gesamte Verwwaltungsinformation dem Dateiformat entprechend codiert wird. Wenn man diese Informationen in der Datenbank speichern wollte, muss man den gesamte RCS-Code "aufbrechen". Die einizige Alternative wäre das Repository selbst in der Datenbank abzulegen. Fragen an die Datenbank, welche Versionen es gibt, wären dann aber nicht möglich. Stattdessen müsste man das Repository wieder auf die Platte schreiben, um die Frage beantworten zu können.

In gewissen Sinne hat ein Versionsverwaltungssystem eben seine eigene "Datenbank", die aber in aller Regel nicht relational ist.

herbivore

S
8.746 Beiträge seit 2005
vor 18 Jahren

Selbst kommerzielle Versionsverwaltungssysteme legen meist die Files selbst gar nicht in der Datenbank ab, sondern verwalten dort nur die einzelnen Revisionen der Files. Es performt schlicht besser, ein File direkt auf das Filesystem zu schreiben, als als BLOB in eine Datenbank.

Alternativ kannst du dir natürlich eine kleine Versionierung direkt in dein DB-Datenmodell einarbeiten. Wenn es dir nur darum geht deine bestehende Anwendung aufzubohren, vermutlich die einfachste Lösung.

Letztlich gibt es ja keine "Versionsverwaltungssysteme" sondern nur Konfigrationsmanagement- oder Dokumentenverwaltungssysteme. Beide kennen "Versionen", aber die Funktionalität drumrum differiert doch stark. Und die willst du noch nichtmal nutzen. Ist ein wenig wie mit Kanonen auf Spatzen.

Also entweder Freeware und die bestehenden APIs nutzen und somit die Datenspeicherung "outsourcen" oder direkt in das DB-Modell integrieren und auf die Kernfunktionen beschränken (HoleLetzteVersion(), HoleVersion(x)).

Was du wählst hängt schlicht von den Features ab, die du im Zusammenhang mit der Versionierung haben möchtest.

Und dann gibt es ja noch deine Anforderung hinsichtlich eines transparenten Filesystems. Das wirst du nicht wirklich selbst machen wollen.... 🙂