karotte
Ich hab ne Verständnisfrage. Ich lese hier immer wieder, von cvs-, svn-, git- Versionen die man nehmen kann/soll. Was heißt das, bzw. wo liegen die Unterschiede?
Ich hab gelesen, das man cvs, svn, git zur Versionsverwaltung, insbesondere von Quelltext verwendet. Da ich nicht programmiere und also sowas nie eingesetzt habe, hab ich nicht so die praktische Vorstellung davon. Wo ist der unterschied, ob jetzt die Versionen eines Programms mit cvs oder svn verwaltet werden? Warum ist die eine Version besser/anders als die andere? Und überhaupt, wer verwaltet damit? Der der Programmiert, arbeitet der mit mehreren Programmen zur Versionsverwaltung?
Dank und Gruß
Karotte
deviant
Programme werden von den Entwicklern z.B. durch cvs, svn, git, bzr verwaltet, damit die Beteiligten mit der jeweils aktuellsten Version arbeiten können.
Die darin gepflegten Versionen sind daher "Entwicklerversionen" und eigentlich nicht für den produktiven Einsatz gedacht - dennoch kann es Vorteile haben, weil Bugs bereits beseitigt oder Features implementiert wurden, die im aktuellen Release noch fehlen.
Da ich nie größere Programme initiiert habe, musste ich mir nie Gedanken darum machen, was nun besser oder schlechter ist; subversion ist allerdings ein Fork von CVS, CVS selbst wird nicht mehr weiterentwickelt.
Bazaar wird, laut wikipedia, zum Beispiel aktiv von Canonical gefördert, die es für Ubuntu benutzen, während mit git, von Linus Torvalds initiiert, unter anderem der Kernel oder Gnome verwaltet werden.
Als reiner Nutzer ist es ziemlich unerheblich, ob ein Programm nun mit git, svn oder bzr verwaltet wird, abgesehen davon, dass man möglicherweise alle installiert haben muss...
Kinch
Bei einem Projekt (nicht notwendigerweise ein Softwareprojekt) arbeitet man für
gewöhnlich mit Dateien, die man im Laufe der Zeit ändert. Die gängigen
Dateisysteme sind nur in der Lage die letzte Version einer Datei zu speichern
und damit besitzt man keine Kontrolle über die Versionsgeschichte einer Datei
(bei vmx ist das zum Beispiel anders. Da ist die Versionsgeschichte einer
Datei auf Dateisystem-Ebene sichtbar). Und insbesondere wenn mehrere Menschen
an einem Projekt arbeiten wird es ohne Versionsverwaltungssystem aufwändig die
Änderungen der einzelnen Beteiligten zusammen zu führen und nachzuvollziehen.
Versionsverwaltungssysteme kann man grob in die Kategorie zentral und dezentral
einteilen. CVS und SVN sind Vertreter des zentralen Ansatzes und git, bazaar,
mercurial, darcs, arch und monotone sind dezentrale Ansätze. Zumindest bei
Opensource-Programmen sieht man schon an der Anzahl der Systeme eine starke
Tendenz hin zu dezentralen Systemen. Die relativ jungen dezentralen Systeme
lösen auch immer stärker SVN und Co ab. Da liegt vor allem auch daran, dass
dezentrale Systeme der Organisation von Opensource-Projekten entgegen kommt.
Daneben unterstützen die Systeme unter Umständen auch sehr unterschiedliche
Features, bzw. die gleichen Features werden sehr unterschiedlich implementiert.
SVN fehlt zum Beispiel die Unterstützung für Tagging oder Branching. Oder das
Branching ist in Mercurial völlig anderes realisiert (über lokale Kopien auf
dem Dateisystem) als bei git (Branches sind Dateisystem transparent).
Die Aussage von „deviant“, dass die Versionen direkt aus dem
Versionsverwaltungssystem nicht für den produktiven Einsatz gedacht sind,
stimmt zwar oft, aber so pauschal nicht. Das hängt davon ab, wie das Projekt
sich organisiert. Bei git könnte man sich zum Beispiel darauf einigen, etwa im
master branch nur fertige releases zu commiten und in anderen branches zu
entwickeln; oder ein Projekt kann auch ganz auf Release-Zyklen verzichten.
karotte
Dank euch für die ausführlichen Erklärungen.
Nochmal ganz allgemein: Verstehe ich das richtig, es gibt im "Normalfall" (häufigerer Fall) eine veröffentlichte Version, die dann in einem Repository oder um AUR landen (eventuell von Archentwicklern mit Patches versehen). Wenn man was neueres haben will oder einen anderen Entwicklungszweig, dann Greife ich direkt auf einen öffentlich zugänglichen Server der Entwickler (?) zu, wo die Versionsverwaltung (git, cvs...) mit den Versionen drauf ist und ziehe mir das was ich haben will. Bzw. wenn ich Glück habe, hat die entsprechende Version schon jemand gezogen und mit nem PKGBUILD ins AUR gestellt und nennt diese dann git-Version (oder CVS oder welche Versionsverwaltung die Entwickler halt nutzen).
Das heißt doch auch, dass es von einem Programm oder einem Projekt (was auch immer es genau sei) nicht eine git-, eine CVS- und eine SVN- etc. Version gibt. Es gibt im Regelfall nur git- oder nur svn- etc. Versionen, je nachdem mit welcher Versionsverwaltung die Entwickler arbeiten (neben dem offiziellen Release was dann meist außerhalb der Versionsverwaltung anzusiedeln ist).
Ist das soweit richtig?
deviant
Ja.
Wobei genau genommen: nein. Die PKGBUILDs verweisen bloß auf die (Entwickler-)Versionen. Insofern ist die Version aus dem AUR dann quasi deckungsgleich mit einer manuell aus dem git/bzr/svn gezogenen Version oder auch einem normalen Release, es ist vor allem komfortabler.
Von den Arch-Entwicklern werden nur die Pakete in den offiziellen Repos gepatched.
karotte
Danke für die Erklärung 🙂
Gruß Karotte
GerBra
Abseits vom Programmieren:
Man kann eine Versionsverwaltung auch ganz gut für Historie/Configbackups von z.B. Verzeichnissen wie /etc "mißbrauchen". Das erfordert dann etwas Disziplin, aber das kann durch den Vorteil wettgemacht werden wenn man z.B. was verkonfiguriert hat, oder auch z.B. um zu sehen welche Änderungen an welchen Dateien durch ein Update kamen.
Oder wenn man ein Buch oder eine Doktorarbeit (latürnich in Plaintext und für LaTex) schreibt, auch da kann man sich die "einfachen" <g> dezentralen wie git zunutze machen um Änderungen am Text zu verfolgen. Das ersetzt natürlich alles kein Backup, aber es erspart z.B. Millionen unterschiedlicher Dateiversionen abzuspeichern. Wie dann "Plagiate und Ich. Das Eigenleben - v001.txt", "Plagiate und Ich. Das Eigenleben - v002.txt"... ;-)
agaida
GerBra schriebAbseits vom Programmieren:
Man kann eine Versionsverwaltung auch ganz gut für Historie/Configbackups von z.B. Verzeichnissen wie /etc "mißbrauchen". Das erfordert dann etwas Disziplin, aber das kann durch den Vorteil wettgemacht werden wenn man z.B. was verkonfiguriert hat, oder auch z.B. um zu sehen welche Änderungen an welchen Dateien durch ein Update kamen.
Genau für diesen Zweck hat Joey Hess mal den etckeeper geschrieben. Mit pacman funktioniert der zwar nicht wirklich so wie geplant bei debian, wenn man den aber nach pacman in ein Script einbindet, macht er halt auch, wofür er geschaffen wurde.
stefanhusmann
deviant schriebVon den Arch-Entwicklern werden nur die Pakete in den offiziellen Repos gepatched.
Gepatched? Meinst du "verwaltet" oder "betreut"? Arch ist eher dafür bekannt, und es ist auch eine seiner Maximen, wenig bis gar nicht zu patchen.
Und natürlich steht es jedem Entwickler frei, auch Pakete im AUR zu haben. Manche haben auch welche.
NoNick
Ich persöhnlich meide es zwar solche Pakate zu installieren, aber hier sei der Hinweis mal angebracht, das die SVN/GIT und Co Pakate besonders geupdatet werden müssen. Für Yaourt heißt dass: yaourt -Syu --aur --devel
mannohneschuh
NoNick schriebIch persöhnlich meide es zwar solche Pakate zu installieren, aber hier sei der Hinweis mal angebracht, das die SVN/GIT und Co Pakate besonders geupdatet werden müssen. Für Yaourt heißt dass: yaourt -Syu --aur --devel
DAMN! --devel Wo ist das dokumentiert das ohne erst gar nicht die svn/git Pakete geupdatet werden?
NoNick
mannohneschuh schriebNoNick schriebIch persöhnlich meide es zwar solche Pakate zu installieren, aber hier sei der Hinweis mal angebracht, das die SVN/GIT und Co Pakate besonders geupdatet werden müssen. Für Yaourt heißt dass: yaourt -Syu --aur --devel
DAMN! --devel Wo ist das dokumentiert das ohne erst gar nicht die svn/git Pakete geupdatet werden?
Im wiki:
https://wiki.archlinux.org/index.php/Yaourt