Versioning-System: Analyse, Wuensche, Kritiken...
Hier eine kurze Zusammenfassung der bereits geschriebenen Beitraege:
Tabellar hat geschrieben: ...Also, vor der Implementierung steht die Analyse!!! Ich moechte alle Leser bitten, ihre Meinungen, Erfahrungen, Kritiken und Wuensche einzubringen in Bezug auf ein Python-SQL-System gegenueber CVS....Oder kurz: Was kann unser System wenn es fertig ist besser als das CVS...
piddon hat geschrieben:Der Vergleich zu CVS darf man nicht zu hoch ansetzen. Man wird es nicht schaffen CVS zu verdrängen. Dafür ist es schon zu sehr etabliert.
Aber man darf auch nicht allzuviel Respekt haben. Man muss es Versuchen. Es gibt bestimmt viele, die CVS für zu kompliziert halten. Ich gehöre dazu. Es ist einfach zu "mächtig", und die Scheu ist gross es einzusetzen. Wenn es was in PYthon gibt, das Userfreundlicher und einfacher zu installieren ist, und dazu noch Plattformunabhängig, so sehe ich darin viel Potential.
joerg hat geschrieben: Ich muß gestehen, daß ich noch nicht viel von CVS kenne, ein paar Projekte habe ich unter Versionskontrolle gestellt, dabei ein bißchen Kommandozeile und die GUIs CerViSia und LinCVS benutzt, aber richtig auskennen tue ich mich nicht.
Was mir an Schwachstellen aufgefallen ist, ist die Netzanbindung. Es ist gut, CVS mit Bordmitteln wie ssh oder rsh bedienen zu können, aber für GUIs ist das grausam. Manchmal bleibt die Shell einfach hängen, und ich weiß dann nicht, ob der CVS-Server ein Problem hat, oder die Shell, oder das GUI...
Mein Vorschlag wäre, eine saubere Schnittstelle über sog. Webservices zur Verfügung zu stellen. XML-RPC ist z.B. ein sehr schlankes und mächtiges Protokoll, und wunderbar in Python integrierbar. Ich habe damit gerade ein kleineres Projekte gemacht, und fände das ziemlich passend für diese Zwecke...
So kann es weitergehen !!!Beyond hat geschrieben: Eine saubere Schnittstelle ist top-priority. Bei CVS ist das echt ungünstig gelöst. Bei einer solchen Schnittstelle finde ich Verschlüsselung noch sehr wichtig (das funktioniert bei CVS + GUI so gut wie garnicht). Gut wäre es auch verschiedene Verschlüsselungs- und Authentifikationsarten zu ermöglichen.
Das bringt uns zu einer weiteren Sache: einfache Server- und Client-Installation. Keine inetd Einträge, ssh-tunnels etc. !! U.U. sollte man in der Schnittstelle eine Möglichkeit zur Remote-Konfiguration vorsehen (das kann man aber später Implementieren).
Ich glaube auch, daß ein Schlüssel für den Erfolg eines solchen Systems eine einfache Handhabung ist.
In meinem Konzept habe ich alle möglichen Dinge die CVS kann vorgesehen z.B.:Features könnten sein:
- Branching
mehrere Projekte
Wiederherstellung von alten Versionen
Synchronisation von Entwicklungscomputern
Offline-Fähigkeit (man muß während des Programmierens nicht mit dem Server verbunden sein)
Automatisches Ausfüllen von speziellen Feldern ($Author$ ... )Auf so ein System freue ich mich jetzt schon
- Erweiterte Benutzerverwaltung
Flexibles Durchsuchen verschiedener Version eines oder mehrer Projekte
Scripting Fähigkeit
Versionsverwaltung von nicht Quellcode-Dateien (Bilder ...)
Unterstützung bei der Erstellung einer Dokumentation
Programmiersprachen-PlugIns
Daten-PlugIns (Bilder, HTML, ... -- z.B. zum Verwalten/Durchsuchen der Metadaten)
robuster als CVS
Nicht nur Versioning von Dateien sondern auch von Verzeichnissen und weiteren Metadaten wie Zugriffsrechte
Verschiedene Checkout-Modi, sodaß z.B. bei einer Version für Endbenutzer Dateizugriffssrechte automatisch richtig gesetzt sind.
und vieles mehr ...
Seit einiger Zeit verwende ich ein CVS-Repository auf einem SSH-Server und greife darauf mit einem Eclipse-GUI und Python/C/C++ Plug-Ins zu.
Die Versionskontrolle funktioniert recht gut und man kann andere Entwickler so relativ einfach an das SourceCode-Root anbinden. Allerdings ist das Einrichten eines solchen SSH-CVS Servers nicht ganz trivial...
Nach doch recht langem Ueberlegen komme ich zu dem Schluss, dass wir mit unserem Versioning-System nicht einfach das CVS und die damit verbundene Programmentwicklung kopieren duerfen. Was mich am meisten am CVS und der Programmentwicklung in Dateien stoert, ist, dass der Ueberblick vom Programm-Codes bei grossen Projekten verloren geht und man entsprechende GUIs braucht, welche aus den Dateien z.B. die Klassen und Funktionen herausfiltern und man so dann schnell an die entsprechende Stelle in der jeweiligen Datei springt. Wenn wir schon ein Datenbanksystem einsetzen wollen, finde ich es zu einfach, dass wir lediglich die ProgrammCode-Dateien in irgendeiner Form in der Datenbank ablegen (z.B. als Textfelder oder BLOBs...).
Wesentlich spannender finde ich es, dass wir Programmcode in funktionalen Einheiten im DMBS ablegen, und an einer anderen Stelle definieren, wie wir Programmteile aus der DB zu einer Programmcode-Datei generieren!
Wir haben so alle Optionen offen:
-Programmcodeuebersicht
-Programmcode-Einheiten
-Flexible Zusammenstellung von Programmbausteinen zu Programmdateien
-...
Erste Ansaetze dieser "Generativen Programmierung(GP)" sind bei dem FrameProcessor-Projekt auf SourceForge.net zu sehen...Aber das ganze ist natuerlich ein eigenes Thema...
Fuer unser Versioning-System sind folgende Punkte meiner Meinung nach zentral:
1. Schnittstelle Client-Server
2. Sicherheit/Verschluesselung
3. Synchronisierung lokales Workspace mit zentralem SourceCode Root
Ich hab mal ein kleines Modell entworfen, wie das ganze aussehen koennte:
Versioning-System als verteiltes System
ueber Webdienste:
...[SourceCode]...[SourceCode]
...[Local..........]. ..[Local ]
...[Workspace ]....[Workspace ]
.........|.......................|
.........o......................o
.........|.......................|
...[Client1]............[Client2]
...[Web/CGI].........[Web/CGI]
.........|.......................|
.........o......................o
...........\.................../
...............\............/
...................\...../
......................o
......................|
...........[ WebServices]
...........[ XML-Switch]
...........[ XML-RPC ]
......................|
......................o
..................../...\
................../......\
................/..........\
............../..............\
............/..................\
...........o...................o
...........|....................|
....[SourceCode]...[XML-DB]
....[ DBMS ]
gruss
tabellar
Die Versionskontrolle funktioniert recht gut und man kann andere Entwickler so relativ einfach an das SourceCode-Root anbinden. Allerdings ist das Einrichten eines solchen SSH-CVS Servers nicht ganz trivial...
Nach doch recht langem Ueberlegen komme ich zu dem Schluss, dass wir mit unserem Versioning-System nicht einfach das CVS und die damit verbundene Programmentwicklung kopieren duerfen. Was mich am meisten am CVS und der Programmentwicklung in Dateien stoert, ist, dass der Ueberblick vom Programm-Codes bei grossen Projekten verloren geht und man entsprechende GUIs braucht, welche aus den Dateien z.B. die Klassen und Funktionen herausfiltern und man so dann schnell an die entsprechende Stelle in der jeweiligen Datei springt. Wenn wir schon ein Datenbanksystem einsetzen wollen, finde ich es zu einfach, dass wir lediglich die ProgrammCode-Dateien in irgendeiner Form in der Datenbank ablegen (z.B. als Textfelder oder BLOBs...).
Wesentlich spannender finde ich es, dass wir Programmcode in funktionalen Einheiten im DMBS ablegen, und an einer anderen Stelle definieren, wie wir Programmteile aus der DB zu einer Programmcode-Datei generieren!
Wir haben so alle Optionen offen:
-Programmcodeuebersicht
-Programmcode-Einheiten
-Flexible Zusammenstellung von Programmbausteinen zu Programmdateien
-...
Erste Ansaetze dieser "Generativen Programmierung(GP)" sind bei dem FrameProcessor-Projekt auf SourceForge.net zu sehen...Aber das ganze ist natuerlich ein eigenes Thema...
Fuer unser Versioning-System sind folgende Punkte meiner Meinung nach zentral:
1. Schnittstelle Client-Server
2. Sicherheit/Verschluesselung
3. Synchronisierung lokales Workspace mit zentralem SourceCode Root
Ich hab mal ein kleines Modell entworfen, wie das ganze aussehen koennte:
Versioning-System als verteiltes System
ueber Webdienste:
...[SourceCode]...[SourceCode]
...[Local..........]. ..[Local ]
...[Workspace ]....[Workspace ]
.........|.......................|
.........o......................o
.........|.......................|
...[Client1]............[Client2]
...[Web/CGI].........[Web/CGI]
.........|.......................|
.........o......................o
...........\.................../
...............\............/
...................\...../
......................o
......................|
...........[ WebServices]
...........[ XML-Switch]
...........[ XML-RPC ]
......................|
......................o
..................../...\
................../......\
................/..........\
............../..............\
............/..................\
...........o...................o
...........|....................|
....[SourceCode]...[XML-DB]
....[ DBMS ]
gruss
tabellar
Hatte eine längere Pause gebraucht ...
Ich musste einige andere Dinge einfach endlich mal erledigt wissen ...
Ich hatte sogar einmal begonnen eine komplett graphische Programmierschnittstelle für Java zu schreiben, bevor ich VisualAge gesehen hatte.
Zunächst sollten wir allerdings offen lassen wie der SourceCode gespeichert wird (das ist in der Version die ich online gestellt habe nicht einmal implementiert). Das hat den Vorteil, dass das System dann sehr anpassungsfähig für Programmiersprachen, Projekte, ... bleibt. Als Grundstrukturierung würde ich aber Dateien beibehalten, da sie ein bekanntes und bewährtes Schema darstellen. Einige Dinge wie z.B. Bilder sind ohnehin nicht anders speicherbar und viele Leutem haben einen lieblings Editor und der versteht meist nur Dateien.
Also halte ich ein zweischichtiges Sysem für sinnvoll:
- 1. Schicht: Verwaltet/Versioniert Dateiartige Objekte
- 2. Schicht: Untergliedert die Dateiartigen Objekte, stellt also weitere Schnittstellen für Unterbereiche eines solchen Objekts zur Verfügung (z.B. Suche nach bestimmten Eigenschaften -- ist aber stark von dem jeweiligen Objekt abhängig: Bilddatei, Python-Code, Config-File, ...)
In der 2. Schicht können dann die o.g. Features implementiert werden
Ich musste einige andere Dinge einfach endlich mal erledigt wissen ...
Ja das ist besser. VisualAge für Java stellt auch solche Features zur Verfügung, aber das könnte man wesentlich weiter treiben.tabellar hat geschrieben: Nach doch recht langem Ueberlegen komme ich zu dem Schluss, dass wir mit unserem Versioning-System nicht einfach das CVS und die damit verbundene Programmentwicklung kopieren duerfen. Was mich am meisten am CVS und der Programmentwicklung in Dateien stoert, ist, dass der Ueberblick vom Programm-Codes bei grossen Projekten verloren geht und man entsprechende GUIs braucht, welche aus den Dateien z.B. die Klassen und Funktionen herausfiltern und man so dann schnell an die entsprechende Stelle in der jeweiligen Datei springt. Wenn wir schon ein Datenbanksystem einsetzen wollen, finde ich es zu einfach, dass wir lediglich die ProgrammCode-Dateien in irgendeiner Form in der Datenbank ablegen (z.B. als Textfelder oder BLOBs...).
Ich hatte sogar einmal begonnen eine komplett graphische Programmierschnittstelle für Java zu schreiben, bevor ich VisualAge gesehen hatte.
Zunächst sollten wir allerdings offen lassen wie der SourceCode gespeichert wird (das ist in der Version die ich online gestellt habe nicht einmal implementiert). Das hat den Vorteil, dass das System dann sehr anpassungsfähig für Programmiersprachen, Projekte, ... bleibt. Als Grundstrukturierung würde ich aber Dateien beibehalten, da sie ein bekanntes und bewährtes Schema darstellen. Einige Dinge wie z.B. Bilder sind ohnehin nicht anders speicherbar und viele Leutem haben einen lieblings Editor und der versteht meist nur Dateien.
Also halte ich ein zweischichtiges Sysem für sinnvoll:
- 1. Schicht: Verwaltet/Versioniert Dateiartige Objekte
- 2. Schicht: Untergliedert die Dateiartigen Objekte, stellt also weitere Schnittstellen für Unterbereiche eines solchen Objekts zur Verfügung (z.B. Suche nach bestimmten Eigenschaften -- ist aber stark von dem jeweiligen Objekt abhängig: Bilddatei, Python-Code, Config-File, ...)
In der 2. Schicht können dann die o.g. Features implementiert werden