2009-09-21T09:28:17 sid burn

Quote

Ich war bisher nicht in der Verlegenheit, so etwas zu machen, aber ich wuerde schlicht und ergreifend ein Versionskontrollsystem nehmen und da die releases reinschmeissen.

Ein Versionierungssystem sollte man letztendlich sowieso nehmen und darüber auch die Releases und versionen pflegen, allerdiengs finde ich nicht das es für einen "Endkunden" akzeptabel ist Git zu nutzen und darüber seine programme zu updaten. Sowas ist dann meiner Ansicht nach doch eher für Entwickler gedacht.

Wieso ist es nicht akzeptable, wenn das Programm sich selbst ueber Git updated? Der Anwender muss davon nichts mitbekommen.

Quote

Vor allem möchte man Endkunden nicht immer Entwickler Versionen anbieten sondern Stable releases.

Deswegen habe ich auch geschrieben, man soll die Releases ins git-repo reinkippen - ich habe nie behauptet, man soll fuer Entwicklung und Verteilung das gleiche Repo benutzen.

Quote

Dann muss man praktisch noch jemanden Git erklären damit dieser in der lage ist zwischen versionen hin und her zu wechseln.

Muss man nicht. Siehe oben.

Quote

Und hoffentlich gibt es keine konflikte, oder ähnliches...

Wo sollen Konflikte herkommen, wenn Updates immer nur vom selben Repo bezogen werden?

Quote

Quote

Git z.B. bietet eine sehr gute Delta-Kompression, damit sind die updates, die man sich herunterladen muss, recht klein.

Wenn man es genau nimmt. Git speichert immer die vollständige Datei bei jedem commit, und die vollständigen Dateien werden auch immer vollständig heruntergeladen/synchronisiert. Deltas speichert Git intern nicht.

Ansonsten weil Git immer die vollständige History enthält muss jeder immer das vollständige Projekt herunterladen mit allen Versionen/Revisionen jeder Datei seit start des Projektes.

Stimmt nicht. Git unterstuetzt "shallow clones", siehe z.B. die --depth-Option in der git-clone manpage.