Hilfe bei Auswahl und Implementierung der Versionskontrolle/-überprüfung/-aktualisierung

Hey, ich habe folgendes vor:

Ich muss eine Hilfe-Datei für eine größere Software ( die Videos, Bilder, HTML-Seiten etc. ) von Docbook in HTML umwandeln und dann zum download auf der Seite anbieten... Soweit so gut!

Jetzt soll ich diese Hilfe aber unter Versionskontrolle stellen ( so, dass sobald der Kunde die Hilfe mit Internet öffnet ( eine .exe, die einen HTML-Viewer startet ) eine Versionskontrolle (IM HINTERGRUND) durchgeführt wird. Dann sollen alle "veralteten" Dateien automatisch ausgetauscht werden, ohne dass der Kunde etwas mitbekommt.
Problem: ich muss ja eine Kopie der "veralteten" machen und ihn auf dieser "arbeiten" lassen. sobald alles fertig geupdatet ist müsste ich ihn dann irgendwie au die neue Datei umleiten, bzw. erst nach dem nächsten Start.

Ich hab das ganze bis jetzt schon mit Subversion versucht (Sharpvsn) also die api für C#.
Jetzt überlege ich noch ob Git vll die bessere Lösung wäre.

Habt ihr da vielleicht Tipps parat? Klappt das überhaupt so wie ich mir das vorstelle?
Git oder Subversion (beziehe mich natürlich bei beiden auf die jeweilige API.

Konkreter^^:
Git oder Subversion für speziell DIESES Vorhaben?
Welche "Vorgehensweise" für das updaten und dann in neue datei wechseln?

Noch kleine Info:
Diese Hilfe-Datei ist ca. 600-700 MB groß und wird bald die 1GB Marke überschreiben, da mehrere Videos eingebunden werden!

Danke schon mal.

MfG

Hallo 123,

Problem: ich muss ja eine Kopie der "veralteten" machen und ihn auf dieser "arbeiten" lassen.

nein, lasse ihn immer auf dem Original arbeiten. Speichere die neue Version woanders.

Schau auch hier : updateSystem.NET

Oder suche hier im Forum nach "Updater".

Dein Anliegen lässt sich aber auch recht einfach mit einem WebClient.DownloadFileAsync() erledigen.

Eine "Versionskontrolle", die GIT oder Subversion durchführt, ist etwas anderes als das was Du benötigst.

Grüße Bernd

Hi unnamed123,

im Prinzip brauchst du doch kein Git o.ä. beim Kunden zu integrieren, da dieser ja eh immer nur die neuste Datei haben soll?! Das Versionsmanagement ist doch für den Entwickler, damit hat der Kunde doch nix zu tun. 🤔
Ich sehe 2 grundsätzliche Möglichkeiten:

1. Du baust den Spaß komplett online auf. Ihr ändert auf eurem Server die Dateien -> Kunde sieht immer die aktuelle Version.

2. Damit der Kunde zum einen immer (also auch bei nicht-verbundenem I-Net) an die Dateien kommt und zum anderen jede aktuelle Datei nur 1x pro Kundenrechner durchs Netz gejagt werden muss, werden die Daten wirklich lokal gespeichert. Ihr stellt die Datei z.B. auf einen FTP-Server und der Viewer sucht bei verbundenem Netz nach neuen Dateien (Zeitstempel!). Bezüglich der Aktualisierung hast du noch weitere Varianten:
   a) Der Viewer hat eine Update-Instanz, die immer im Hintergrund läuft -> wie Dropbox o.ä.
   b) Der Viewer sucht beim Start nach neuen Dateien. Wenn er welche findet, kann man mit allen Dateien die aktuell sind weiter arbeiten und die Inaktuellen werden solange gesperrt, bis sie geladen sind.
   c) Möglich, aber nicht schön: Programm startet -> sucht nach Updates -> findet welche -> zeigt einen modalen Ladebalken -> Kunde holt sich Kaffee -> Kund ruft dich an ... 😁

Ezio

Ok Danke schon mal für die Antworten. Werde mich mal über das von euch empfohlene informieren udn werde dann sehen, ob das funktioniert.

Aber dann weiß ich jetzt schon mal, dass ich auf dem "Holzweg" war 😉

@Ezio:
Zu 1):
Ja nur ist es so, dass die oft kein I-net haben und daher wird verlangt, dass das auch sozusagen "Zum Offline lesen" gespeichert werden kann.

EDIT: Ach was ich noch sagen wollte:

An das mit dem zeitstempel hab ich erst auch gedacht(also rekursiv durchsuchen ), da ist aber das Problem, dass wir ja so wenig wie möglich updaten wollen und daher wirklich dei einzelnen Dateien überprüfen müssen.
Wenn ich da dann mal schnell tausende Anfragen an den Server sende, kann da kompliziert werden. Außer du wüsstest da auch ne Alternative!!
mfg

@BerndFfm:

hatte das gestern auch schon einmal mit "WebClient.DownloadFileAsync()" gemacht. bzw. das ganze in "klein" aufgesetzt und getestet.
Aber wie genau würdest du das machen?
Nein ich möchte keinen fertigen Code etc. haben udn ja ich hab die Forenregeln gelesen

sondern nur deine Idee dahinter. Ebenfalls mit einem "Timestamp" vergleichen? Oder gibt es da sogar eine Funktion / Anwendungsweise, bei der die Daten selbstständig abgeglichen werden.

Bisher hab ich das eben so mit den "FtpWebRequest" und "FtpWebResponse" gemacht und dann eben den DateTimeStamp angefordert und verglichen. Nur da bekomme ich dann bei 2000+ Dateien Probleme.

Ich habe aber noch eine Idee, wie du das alles noch etwas effizienter gestalten kannst:

• jeweils auf Server- und Clientseite das Datum des letzten (erfolgreichen) Updates hinterlegen und vergleichen
  -> damit kann schonmal unnötiges Durchsuchen verhindert werden.
  Zusätzlich kennst du ja nun auf Clientseite nur das Datum des letzten Updates, kannst aber auf Serverseite eine einfache (Text-)Datei, die alle Dateinamen mit letztem Änderungsdatum enthält, erstellen. Mit dem Datum des Clients filterst du alle Dateien heraus, die erneuert werden müssen.
  Vorteile:
  Damit ersparst du dir, alle Verzeichnisse durchsuchen zu müssen und von jeder Datei das Änderungsdatum zu holen.
  Probleme:

1. Falls der Kunde versehentlich eine Datei gelöscht haben sollte, würde diese Methode das zumindest so grundsätzlich erstmal nicht abfangen!
   1a) Musst dir noch was für neu hinzukommende bzw. wegfallende Dateien überlegen
2. Pflegeaufwand der Versionsdatei auf deiner Seite.

Ezio

@BerndFfm: Aber wie genau würdest du das machen?

Ich hatte das mal für mein Projekt "Kleine kostenlose Textverarbeitung" in 10 Minuten so gemacht :

Upload in einer Batchdatei :

date <nul >Versionsdatum.txt
ftp -s:upload.ftp

Download in C# :

DateTime dat = new DateTime(2999, 1, 1);
WebClient cl = new WebClient();
string str = cl.DownloadString(DownloadServer() + "Versionsdatum.txt");
string[] fld = str.Split('\r');
if (fld.Length > 0 && fld[0].Length >= 10) DateTime.TryParse(fld[0].Substring(fld[0].Length - 11), out dat);
if (dat > Versionsdatum)
{
	// Update laden ...
}

Prüfe immer nur eine Datei auf das Datum, nicht alle.

Grüße Bernd

Hallo,

vielleicht helfen dir die Artikel der Dotnetpro etwas weiter.
Dort gab es eine Artikelserie in der eine Update-Funtkion mit FTP und was dazu gehört realisiert wurde.

Dotnetpro > Archiv > File Transfer Protocol (FTP)

(da fehlt die Ausgabe 10/2013)

@ProGamer:
Danke werd ich mir morgen mal anschauen!

@BerndFfm:
Hab mich jetzt ne Weile mit updateSystem.NET auseinandergesetzt und bin leider zu dem Entschluss gekommen, dass das nicht das ist was ich suche. Ganz einfach weil an der Hilfe sehr viele Leute Sachen ändern und nicht erwünscht ist, dass jeder das mit den Updates eingeben muss etc. ... das wäre einfach zu umstänlich.... zusätzlich werden diese Hilfedateien MINDESTENS wöchentlich geändert.
Danke trotzdem

@Ezio:
An das habe ich auch schon gedacht, nur werden spätestens wöchentlich wieder Übersetzungsupdates geladen und meist auch etwas hinzugefügt bzw. abgeändert...... Daher ist das auch zu umständlich und die Version würde so gut wie nie übereinstimmen.

Habe wie gesagt schon ein Programm geschrieben, das mir alle "LastModified"- Daten rausschreibt und ich dann Zeile für Zeile vergleiche und mir dann die entsprechenden hole. Da häng ich dann aber an dem Problem, wenn etwas gelöscht / hinzugefügt wird.....

Muss ich wohl noch weiterüberlegen... ziemlich verzwickt das ganze.

Hallo unnamed123,

ich verstehe nicht, wo du ein Problem siehst. Auf dem Server steht, so wie ich es verstanden habe, die jeweils aktuellste Version. Wenn diese neuer ist als die lokale Version oder die lokale Version gelöscht wurde, lädst du sie herunter. Im Zweifel zunächst in ein ((neues) temporäres) Unterverzeichnis. Aus diesem kannst du dann die lokale Version ersetzen kannst, nachdem der Download vollständig ist. Klar, dabei muss man mit Zeitstempeln arbeiten, aber wie das geht, steht in der Doku, z.B. FileSystemInfo.LastWriteTimeUtc. Auf dem Server kann man den Zeitstempel auch leicht abfragen, im Zweifel aus einer extra Datei, wie BerndFfm das vorgeschlagen hat.

Ich habe das für eine einzelne Datei beschrieben. Das lässt sich aber problemlos auf mehrere Dateien erweitern.

Ich sage mal so: Wenn man die Grundlagen beherrscht, kann man das einfach runterprogrammieren. (Deshalb verweise ich vorsorglich mal auf [Hinweis] Wie poste ich richtig? Punkt 1.1.1

Hi unnamed123,

ich wiederum sehe kein Problem in der Verwendung einer existierenden Versions-Kontroll-Verwaltung.

Ich würde einfach Git nehmen und über libgit ansprechen. Git unterstützt auch Binary Diffs, sollte also auch damit klarkommen.

Du musst ja auch bedenken, dass du für eine solche Versionsverwaltung sowohl Client als auch Server umsetzen müsstest. Und zudem für effiziente Übertragung eine Diff-Implementierung.

Gleichzeitig bietet Git von Hause aus die Möglichkeit zu branchen.
Vielleicht gibt es die Hilfe später in mehreren Sprachen je nach Lokalisierung des Clients? Sicherlich möchtest du auf Serverseite auch die alten Versionen irgendwo noch archivieren - dann müsste der Server schon mehr können. Zudem können Mitarbeiter einfach mit einem eigenen Git-Client die zentralen Hilfe-Dateien updaten. Und und und ...
Klingt also eigentlich ganz gut 😃

Ich muss zugeben, ich selbst habe es noch nie verwendet und noch nicht gebraucht. Aber wenn, würde ich glaube ich über Git gehen 😃

beste Grüße
zommi

Lass den Kunden, doch nach dem Start erst mal Online arbeiten. Dann hat er ja schon mal die aktuelle Version 😉

Dann kannst du in Ruhe, die Dateien Downloaden. Vielleicht irgend wie mir der Endung Temp. Wenn der Download abgeschlossen ist. Benennst du die Alten Dateien um zb mit der Endung Old (Das geht recht schnell, dann den neuen Dateien die Passenden Namen geben. Dann den Kunden Lokal Arbeiten lassen und die alten Daten Löschen.

Du kannst natürlich auch den Kunden erst mal Lokal Arbeiten lassen, dabei die Daten downloaden und dann bei Beendigung des Programms die Dateien umbenennen. Grundlegend ist es sogar direkt nach nach dem Download möglich.

@herbivore:
Ja eben so nicht. Ich möchte ja nicht jedes mal das ganze Paket downloaden, das könnte je nach Internetanbindung des Kunden mehrere Stunden dauern.
Und eine der Hauptanforderungen ist, dass es schnell geht und der Kunde davon nichts mitbekommt.
(Die Hilfe Datei kann wie gesagt bis 1GB groß sein und noch größer werden.

@zammi:
Dann schau ich mir Git auch mal genauer an.

@Palin:
Wenn der dann nach dem Start wieder online arbeitet bemerkt der Kunde ja schon wieder etwas... siehe Hauptanforderung oben.

Hallo zommi,

Grundsätzlich habe ich auch nichts gegen Versionsverwaltungen und viel dafür. Man kann das sicherlich machen, wenn man sich der Konsequenzen bewusst ist.

Die Diff-Übertragung könnte gerade bei großen Dateien tatsächlich ein wichtiger Vorteil sein.

So weit, dass man auf dem Client auch ein Repository hat, würde ich aber nicht gehen.

Allerdings braucht der Client wohl mindestens eine DLL für den Zugriff auf remote repositories. Sowohl Web- als auch FTP-Download kann das .NET-Framework jedoch von Hause aus, so dass man damit ohne externe DLLs auskommt. Nicht das externe DLLs schlimm wären, aber im Forum liest man immer wieder, dass Kunden oder Chefs vorgeben, dass externe DLLs nicht genutzt werden dürfen oder die Entwickler das von sich aus nicht wollen.

Auch muss man darauf achten, dass gerade weil dann (auch) ein Zugriff mit einem normalen Versionsverwaltungsfrontend möglich ist, dass die Zugriffsrechte auf den remote repositories korrekt gesetzt werden. Sonst könnte womöglich ein Dritter ungewollt oder gezielt eine neue Version einstellen oder vorhandene Versionen löschen. Lösbar, klar, aber man muss (immer) daran denken.

Wenn man dagegen einen Web- oder (anonymous) FTP-Download anbietet, hat man die Zugriffsrechte (mehr oder weniger) automatisch bzw. standardmäßig im Griff. Und der Benutzer hat, wenn man die alten Versionen in eine Verzeichnisstruktur packt, genauso die Möglichkeit mit Standard-Clients (Browser, FTP-Client) alte Versionen herunterzuladen. Sofern das beabsichtigt ist. Wenn nicht stellt man eben nur die aktuelle Version zur Verfügung.

Sicherlich möchtest du auf Serverseite auch die alten Versionen irgendwo noch archivieren - dann müsste der Server schon mehr können.

Der Enwicklungsserver wird sicher eine Versionsverwaltung haben (müssen). Der Web- oder FTP-Server muss aber nicht unbedingt mehr können. Dorthin könnte vom Entwicklungsserver einfach die aktuelle Version ausgechekt und somit für den Download zur Verfügung gestellt werden.

Hallo unnamed123,

bisher hattest du von der Größe der Dateien nur als "kleine Info" am Rande geschrieben. Jetzt schreibst du so, als wäre das der zentrale Punkt. Was denn nun? Was genau sind deine wirklichen und aktuellen Hauptanforderungen?

herbivore

Absolut wichtig ist:
-Der Kunde bekommt von dem ganzen update ABSOLUT gar nichts mit!
(Oft haben die an den entsprechneden Rechnern Wochenlang kein Internet )

• Die Lösung muss für große Dateien geeignet sein. (Ne normale Hilfsdatei mit ~1-10MB wäre natürlich kein Problem.

Ich hab inzwischen schon 3-4 fertige Lösungen gemacht. Aber immer gibt es irgendein Problem:

• Textdatei mit Änderungsdaten ----> neue und gelöschte Dateien verfälschen die Datei
• Datei für Datei überprüfen und über async downloaden -----> dauert einfach zu lange und sind zu viele Anfragen.
• updatesystem.net -----> software auf unserem Server von Mitarbeitern nicht erwünscht

Jetzt werd ich dann mal noch versuchen die Hilfe evtl. umzustrukturieren.
In einzelne Sprachen sind die schon aufgeteilt. Nur diese updaten ist ja weiter kein Problem und werd ich auch so machen. JEtzt werde ich versuchen diese ~600-700 Dateien in kleine Pakete umzusortieren und eventuell so eine neue Struktur zu erreichen. So könnte ich dann immer ganze Pakete updaten, die dann irgendwo bei ~5MB liegen.

Hallo nochmal,

ich würde ganz grundlegend von FTP abraten und HTTPS empfehlen.1.Es ist nicht garantiert, dass aus jedem Firmennetz FTP funktioniert.
HTTP(s) hingegen hat eine höhere Abdecking.

1.Es ist unverschlüsselt - was bei diesen Daten sicherlich nicht sonderlich schlimm ist - aber vielmehr noch beitet es keine Authentifizierung des Servers. Und beim Kunden ein Programm zu installieren, was automatisch im Hintergrund Daten von nicht überprüfbaren Quellen auf die Festplatte runterlädt und bestenfalls noch sofort im Browser öffnet ... Klares Nein.
Natürlich gibt es SFTP und FTPS, aber beides brauch nochmal wieder andere Ports, was in noch weniger Firmennetzen garantiert ist und meines Wissens sind die C#-Libs auch hier wieder nicht von Hause aus im .NET Framework.
Und ja, du könntest einen eigenen Authentifizierungsmechanismus einbauen, vielleicht sogar die Datei-Pakete selbst signieren. Aber du willst ja auch mal fertig werden 😉

Daher ein klares Votum für HTTPS.
(und vielleicht eben auch Git über HTTPS 😉 )

beste Grüße
zommi

@unnamed123
Bei der 2. Variante und den Austauschen der Daten beim Beenden des Programms, wird der Benutzer eventuell nur Feststellen das die Hilfe sich nach einem neu Start geändert hat.

MFG
Björn

• Datei für Datei überprüfen und über async downloaden -----> dauert einfach zu lange und sind zu viele Anfragen.

Wie wäre es denn wenn Du nur eine Datei lädst, eine Liste der Dateien mit den jeweiligen Änderungsdatum. Das geht ja fix.

Oder ist das deine Lösung 1 ? Wenn die nicht funktioniert hast Du sicher einen Denkfehler drin.

Grüße Bernd