CRE130 Verteilte Versionskontrollsysteme

Veröffentlicht am von

Nach Jahren der Stagnation eröffnen verteilte Systeme neue Perspektiven der Kollaboration

Episode image forCRE130 Verteilte Versionskontrollsysteme

Versionskontrollsysteme (DVCS) waren lange Zeit eine Domäne von Programmierern und Systemadministratoren, gewinnen aber in letzter Zeit auch zunehmend Bedeutung für andere kreative und kollaborative Tätigkeiten. Nachdem sich lange Zeit nur zentralistische Systeme wie CVS und Subversion auf dem Markt befanden, kommt jetzt eine neue Generation verteilter Systeme auf, die neue Voraussetzungen schaffen. Im Gespräch mit Tim Pritlove führt hukl in die Prinzipien der verteilten Versionskontrolle ein und bringt zahlreiche Beispiele, wie Entwicklung und Kollaboration durch neue Werkzeuge wie git, mercurial oder bazaar vorangebracht werden können.

Themen: Online und Offline arbeiten, die Vereinfachung von Forks, warum man Verteilte Versionskontrolle für den Friedensnobelpreis vorschlagen könnte, verlustfreie Vergangenheitserfassung, Interoperabilität von verteilen Versionskontrollsystemen, Integration mit alten Infrastrukturen, Social Coding und neue Kollaborationsstrukturen beim Programmieren, Verwendung von DVCS zur gemeinsamen Erarbeitung von Büchern, Nachträgliches Ändern der Versionsgeschichte, Migrationsstrategien.

avatar
John "hukl" Bader
GitHub Icon Twitter Icon
avatar
Tim Pritlove
Twitter Icon @timpritlove@mastodon.social Icon Website Icon Spenden via PayPal Icon
avatar
Max Merz
Shownotes
Pinboard Icon Twitter Icon
Shownotes

91 Gedanken zu „CRE130 Verteilte Versionskontrollsysteme“

  1. Danke für den neuen Podcast, werd ihn mir gleich beim essen reinziehen :)

    Auf das Thema warte ich in der Tat schon länger, Link-liste lässt vermuten es läuft auf GIT hinaus, warum auch nicht.

    Antworten ↓

  5. Ich bin zwar aus Benutzer-Sich auch der Meinung git, hg und bzr sind sehr ähnlich und es ist im Prinzip egal was man verwendet. Aber es gibt ein/zwei Punkte die mir git etwas suspekt mache. Zum einen scheint Linus Torvalds weder OOP noch Abstraktion zu mögen. Das macht mir eigentlich auch Kopfzerbrechen bezüglich Linux, zumal es das OS ist, das ich verwende und ansonsten auch mag. Diese Abneigung zu Abstraktion führt zum einen Zwar zu Performance, andererseits führt’s auch dazu, dass die standard C String Funktionen verwendet werden, wie strcpy udG. Die Funktionen kennen natürlich auch kein Unicode und man muss explizit strncpy mit der richtigen Variable für die Länge verwenden, um sicher zu programmieren. Brrr.

    Das andere ist, das ich sowieso der Meinung bin, dass das meiste einer Versionskontrolle ohne Probleme in einer Hochsprache geschrieben werden kann. Nur Performance kritische Teile brauchen C/C++ sein. Dann ist man auch OS unabhängiger. Nicht umsonst hat git unter Windows den ruf ein wenig ein Alien zu sein. (Weiß nicht ob sich das schon gebessert hat.)

    Aber das klingt jetzt nach einer größeren Kritik als es eigentlich ist. Finde es z.B. auch gut das KDE nach git migrieren will. Hg würde mir *persönlich* zwar besser gefallen, aber git ist schon super.

    Antworten ↓

  7. PS: Wegen GUI Frontend: Also es gibt TortoiseGit und TortoiseHg. Der unterschied der beiden ist, dass es TortoiseGit scheinbar nur für Windows gibt. TortoiseHg ist in Gtk+ geschrieben und gibts für Windows und Linux.

    Antworten ↓

  8. Auch ein Grund für History rewrite: Aus rechtlichen Gründen. Man will was open source machen aber ein Teil deiner Software ist vom Copyright anderer betroffen. Du willst aber natürlich auch die History veröffentlichen. Da ist es natürlich nett, dass man das machen kann.

    Antworten ↓

  9. Ok, noch was: Das Problem mit einen Checkout aus einen Subversion Repo mit z.B. Hg ist, dass SVN user oft riesige Binary Files commiten und auch oft viele Änderungen daran. Beim Konvertieren kann man das zwar filtern, aber dann ist es eben eine Konversion, kein clone. Und aus irgend einen Grund ist das bei hg noch sehr lahm (das Konvertieren). Keine Ahnung was da falsch läuft, denn es gibt dabei weger hohe CPU Last noch hohe Netzwerk Last. Komisch.

    Weiß jemand ob das Git besser macht? Also im Speziellen das „clonen“ von SVN Repos mit reisen Binary Files. Als Bsp. probiert das blender Repo zu clonen: https://svn.blender.org/svnroot/bf-blender/trunk/

    Da müsste man das trunk/lib Verzeichnis filtern. Keine Ahnung warum die das da drin haben. Ich hab mal das alles mit hgsubversion cloned (Da ist es eben keine Konversion, dafür kann man nix filtern. Mal schaun wie das mit der partial clone extension sein wird.) und das ergab dann ein > 900 MB HG Repo. Uff.

    Antworten ↓

  10. gitk ist nicht Gtk. Es ist tk und entsprechend hässlich. Ich mag da hgtk viel lieber (das ist Teil von TortoiseHg – der Teil den ich verwende da ich die Nautilus Integration nicht verwende (KDE User)).

    Antworten ↓

  11. Ok, das ist aber jetzt das Letzte was ich schreib:
    Das was an hg noch fehlt, aber gerade in Arbeit ist, sind partial clones (nur bis zu einer gewissen Revision bzw. nur ein Verzeichnis oder so) sowie… oh, nein. rebase gibts ja mittlerweile schon integriert. Also partial clones fehlen mir noch. git hat noch diesen stagin Bereich. Aber wozu benötigt man dien überhaupt?

    Antworten ↓

  13. Ich habe nicht gezählt wie oft „genau“ gesagt wurde, aber einmal hab ich gezählt wie oft ein Prof. an der Uni (TU Wien) in einer Vorlesung „äh“. Gesagt hat. Eigentlich hab ich erst 15 Minuten nach Vorlesungsbeginn zu zählen begonnen. Ich glaub ich bin auf 500 od. so gekommen. Und eigentlich sagte der nicht „äh“ sondern „ah“ was besonders blöd ist, denn er hat Code mit Variablen „a“, „b“, „c“, … erklärt. Yay.

    Antworten ↓

  16. Super Sendung hab das gestern Abend noch mit Begeisterung gehört.

    Was sich mir als Frage stellt ist wie mercurial oder auch git mit großen Dateien umgehen.
    Auf Arbeit gibt es das Problem das die ganzen Resourcen wie Grafiken, PDFs, sowie DLLs in Binärcode mit im Projekt liegen und nat. auch versioniert werden müssen.
    Mit svn geht das ganz gut nur wird das Repro mit der Zeit langsam und riesen groß.
    Wie sieht es da bei den dezentralen Systemen aus gibt es Probleme mit binär Dateien?

    Antworten ↓

  18. @8jean: In der Tat war sein Rant gegen C++ gerichtet, aber er hat auch die Behauptung aufgestellt Abstraktion sei böse. Und Abstraktion ist ein fundamentaler Bestandteil von OOP. Ich weiß das manche Teile des Kernels OOP sind. Darum hats mich ja besonders erstaunt, was er in diesen Thread von sich gegeben hat.

    Antworten ↓

  19. Wäre schön gewesen, wenn auch auf Darcs hingewiesen worden wäre, zumal dies mit dem patchorientierten Ansatz doch ein wenig anders als git, hg und bzr funktioniert.

    Antworten ↓

  21. Vielen Dank für diesen informativen Podcast. Auch ich schiebe DVCS schon einige Zeit vor mir her. ;-)

    Im Podcast habt Ihr erwähnt, dass lokale Branches nicht wieder in das Hauptrepository wandern. Bedeutet das, dass alle im lokalen Repository gemachten Änderungen nicht in das Hauptrepository zurückgeschoben werden?

    Antworten ↓

  23. @nb: Ich weiß. Trotzdem kenne ich Leute die erfolgreich mit Darcs arbeiten. Mir ging es nur darum, dass es in einem Podcast mit dem Thema „Verteilte Versionskontrollsysteme“ nicht unerwähnt bleiben sollte. Ich persönlich benutze für fast alles git und für einige spezielle Sachen hg.

    Antworten ↓

  24. @joede Prinzipiell hast du zumindest bei git die Wahl welche lokalen Branches du auf remote repositories pushen willst. Du kannst natürlich alles auf beliebig viele andere remote repositories pushen – du musst nur nicht. Wenn du lokal einen Branch hast „Mein geheimes Feature“ und willst den einfach nicht auf github haben, dann kannst du den einfach nicht dort hin pushen.

    Grüße, hukl

    Antworten ↓

  25. @hukl mir ging es eigentlich nicht direkt um die Branches, sondern die lokalen Revisionstände. Die gehen dann ja auch unter? Oder werden alle gespeichert? Wenn ja, werden alle lokalen ge“merge“t, oder sind alle lokalen Änderungen/Revisions (zwischen pull und darauffolgendem push) nach dem push wie ein Branch+Merge? Weißt Du worauf ich hinaus will? Mir wäre es wichtig, dass die History der lokalen Änderungen im Hauptrepository nicht verloren geht.

    Antworten ↓

  26. Ein wichtiger Unterscheid zwischen HG und Git ist sicherlich das Branchhandling. Während bei Git branches nur in dem DAG existieren und die eigentlichen Branchnamen lediglich pointer zu einem Punkt im DAG sind, wird in HG der Branchname in das Changeset geschrieben. D.h. man kann immer feststelle zu welcher Branch ein Changeset mal gehört hat und die Branches werden mitversioniert. Löscht man bei Git einen branchnamen ist er weg und kann nicht wiederhergestellt werden. HG arbeitet dahingehend ähnlich wie CVS.

    Antworten ↓

  27. und noch eine Anmerkung: hg hat neben den SHA1 als commit identifiern für jedes lokale repository noch eine fortlaufende Integer nummer ähnlich der SVN Rev nummer. Diese gelten natürlich nur lokal und sind von Repository zu Repository verschieden.

    Antworten ↓

  28. @joede Um ehrlich zu sein, so richtig versteh ich nicht worauf du hinaus willst. Aber ich glaube deine Sorgen sind unbegründet. Wenn du einen privaten und einen öffentlichen Branch hast und vom privaten auf den öffentlichen mergest hast du auf dem öffentlichen ja die changes des privaten. Geht nix verloren. Die Leute können zwar den privaten Branch selbst nicht sehen aber die changes dann sehr wohl auf dem öffentlichen. Später könntest du dich entscheiden den privaten auch öffentlich zu machen. Oder du machst es von Anfang an. Du bist da total frei. Verloren geht eigentlich nichts es sei denn es ist explizit erwünscht wie z.B. beim history rewrite.

    Antworten ↓

  29. @hukl: DU hast mich richtig verstanden. Ich dachte, dass die lokalen Änderungen –also die Zwischenstände, ich ich nur im lokalen Repository habe– nicht mit übertragen werden. Also so wie der Branch nur lokal vorliegen. Das scheint ja dann nicht der Fall zu sein.

    Wie macht das dann GIT? Ist der Strang im lokalen Repo dann wie ein Branch im Hauptrepo?

    Fiktives Beispiel einer Datei (foo.txt) mit RCS-Like Revisions ;-)

    HauptRepo HR| lokal. Repo LR|
    —————————–
    1.4 wird geCLONEt
    1.5@HR | 1.5@LR |
    … | 1.6@LR |
    1.6@HR | 1.7@LR |
    … | 1.8@LR |
    hier erfolgt PUSH

    Jetzt müßte doch im Hauptrepository ein Merge der 1.6@HR mit der 1.8@LR aus dem lokalen Repo liegen. Die Änderungen 1.5@LR bis 1.7@LR sollten dann ja auch im Hauptrepo liegen. Wie? Liegen die Parallel wie ein Branch?

    Antworten ↓

  31. Ist so ein „privater“ branch auch mit hg möglich? Also kann man bei hg irgendwie sagen, das ein gewisser branch nicht gepusht werden soll?

    @joede
    Zumindest bei hg sind nach einen push/pull (u. ggF. merge) zwei repos ident. D.h. beide haben genau die selbe history (außer wie schon erwähnt wurde die lokalen revisionsnummer). Da geht nix verloren. Die repositories werden quasi synchronisiert.

    Antworten ↓

  32. und genau so ist das auch bei git es sei denn man mag einen bestimmten branch nicht in dem anderen repositoriy haben. Macht es euch alles nicht komplizierter als es ist ;) Im Zweifel probiert es einfach mal eben aus ;)

    Antworten ↓

  33. Ich verstehe nicht so recht, warum alle so begeistert sind von diesem Podcast. Der Gast hat keine Ahnung von CVS, wenig von SVN und mutmaßt dann rum oder erzählt vom Hörensagen. Git toller SVN toller CVS, keine Frage – Ausnahmen bestätigen die Regel, besonders bei SVN toller CVS, aber vieles ist Falsch oder falsch dargestellt. Schade, ein echter Profi wäre toll gewesen.

    Antworten ↓

  34. @Sebastian
    Na dann erzähl doch mal was sooo falsch war. Ich kann Hukls Erfahrungen und die Erläuterungen nachvollziehen und bestätigen. Auch von CVS nicht im Detail angegangen wurde (das Thema war ja auch DVCS und nicht CVCS) sind doch die Nachteile von CVS und generell von zentralen VCS aufgezeigt worden.

    Ich benutze (gezwungener Massen) immer noch CVS bei meinem neuen Arbeitgeber und komme eigentlich von SVN zu GIT zu CVS. Da fühlt man sich dann schon irgendwie gequählt :)

    Und bei 100 Entwicklern an unterschiedlichen Standorten und zentralen Buildsystem, muss man dann schon ein paar Tage warten bis der Build wieder mal durchläuft. Bzw. alle reissen sich zusammen und committen erst, wenn mal wieder ein Build durchgelaufen is. Tja.

    Was ich auch festgestellt habe is, dass generell grössere Changesets committed werden in CVS/SVN, so ganz nach dem Motto „Fixes Bug 23400“ und beinhaltet 200 Linechanges.

    Auch so Refactoringgeschichten ohne lokales Branching wie in Git. NO WAY.

    Man kann auch mal den Lehrling Code ändern und committen lassen und dann ein Codereview machen, und erst Mergen wenn er alles sauber ausprogrammiert hat.

    Dann die ganze Organisation in Unternehmen: Z.B gewisse Abteilungen arbeiten nur an gewissen Modulen. git-submodule lässt grüssen. Mit CVS kann man sich die Oranisation eigentlich ans Bein streichen, weil kontrollieren kann man es eh nicht. Mit Git kann man jeden erdenklichen Workflow/Organisation einer/mehreren Firma/en abbilden.

    Also wie Hukl schon gesagt hat könnte man Stunden fülllen mit Git, weil es soooo flexibel ist. Aber es macht lässt alles auch so einfach aussehen.

    Kurz und Gut. Vom Primitiven zum Komplexen zum Einfachen. Git dann wohl letzteres…

    Thx

    Antworten ↓

  35. @Sebastian es ging ja nicht um centralized version control system sondern um dezentrale. Wir wollten auch garnicht die Klassiker detailiert aufgreifen sondern die konzeptionellen Unterschiede darstellen (zentral vs. dezentral). Ich wäre aber sehr daran interessiert was du als falsch dargestellt empfindest. Ich weiss schon wie CVS und SVN funktionieren hatte aber schlicht nicht den Bedarf gesehen das jetzt ganz genau auseinander zu dröseln.

    Antworten ↓

  38. Nur mal so am Rande zum Thema BLOBs in git:
    Das automatische Mergen ist natürlich immer ein Problem, zwei JPGs zusammenzumatschen ergibt natürlich nicht immer was lesbares, was man aber gut machen kann ist zumindest einen sinnvollen DIFF für BLOBs zu generieren. Ich habe das mal auf meinem Blog zusammengestellt (http://the-gay-bar.com/index.php?/archives/282-Versioning-PDF-files-with-git/). Die Idee dabei ist, ein Tool zu definieren , welches eine textuelle Repräsentation eines BLOBs erzeugt und diese gegeneinander zu DIFFen: So könnte man z.B. ein Script schreiben mp3_2_txt, welches einfach die ID3 Infos als Text darstellt, bindet man das in git ein, so würde man bei der Veränderung der Datei dann sehen, dass sich in der Textrepräsentation z.B. die Zeilen „Title“ und „Filesize“ verändert haben. Die Herausforderung ist dabei also nur eine sinnvolle Textuelle Repräsentation des BLOBs zu finden.

    Ich wollte das auch mal für Bilder hinbauen, um wirklich zu sehen, was sich auf den Bildern verändert hat, aber Bilder sind eher flächen als zeilenbasiert, da scheitert das ein wenig ;)

    Antworten ↓

  39. @sebastian: Nach Linus Torvalds Termininologie bist Du „Ulgy & Stupid“ [1]. Ich teile seine Ablehnung gegenüber CVS/SVN. Wer mit mit diesen Tools gearbeitet hat und danach Git oder etwas Vergleichbares ein paar Tage genutzt hat, der geht nicht wieder zurück. Spätestens nach dem ersten

    git svn clone … [2]

    ist man für die SVN Welt verloren. Außer um einen bestehenden Status Quo zu huldigen, für Irgendjemanden der mehr Macht hat als man selber, sehe ich keinen Grund an diesen Bremsklötzen festzuhalten.

    [1] http://www.youtube.com/watch?v=4XpnKHJAok8

    [2] Es gibt weitere Möglichkeiten einem zentralen Codegefängnis auszubrechen und gleich alle Branches / Histories etc. mitzunehmen.

    Antworten ↓

  40. So, ich habe mich durchgerungen hier im Büro mal GIT zu testen. Ich muss gestehen, dass wir hier auch noch CVS verwenden. Frei nach dem (unsinning) Motto „never change a running system“. :-(

    Leider finde ich nur Anleitungen, mit denen ich mit „git cvsimport“ ein einzelnes Projekt importieren kann.

    Gibt es auch eine Lösung, mit der man ein komplettes CVS-Repository auf einmal importieren kann?

    Antworten ↓

  43. @hukl: Danke, so oder so ähnlich steht es auch in der offiziellen Doku. Leider geht das nur modulweise. Also muss ich doch ein Script schreiben — war zu faul. ;-)

    Wie funktioniert GIT eigentlich auf der Kommazoeile von Windows? Geht das auch? Was ist mit den „line endings“? CVS hat sich immer automatisch darum gekümmert, dass die Zeilenenden konsistent waren. Macht das GIT auch?

    Antworten ↓

  44. Autsch. Ich habe gerade folgendes gelesen: „Multiple tags on the same revision are not imported“. Das ist natürlich fatal. Hat das schon mal jemand „durchlitten“?

    Antworten ↓

  47. @hukl: weißt Du, ob cvs2git aus dem cvs2svn Paket besser funktioniert als git-cvsimport?

    Ich habe mal ein kleines Projekt(chen) in git importiert, das hat soweit funktioniert. Ob die komplette History OK ist, das läßt sich ja nur schwer überprüfen.

    Zu den Windows-Zeilenenden hast Du keine Infos? Konkret geht es darum, das ich unter Linux und meine Kollegen und Windows arbeiten. Zur Zeit checkt jeder das Projekt mit CVS aus, sodass CVS die Zeilenenden je nach Zielplattform korrekt erzeugt. Beim commit geht es dann den anderen Weg. SO bekomme ich dann keinen Misch-Masch aus Linux / Windows Zeilenenden.

    Antworten ↓

  48. @dsp_ leider kennt mein hg unter Ubuntu (Jaunty) kein convert.

    $ apt-cache policy mercurial
    Installiert: 1.1.2-2ubuntu1

    $ hg convert
    hg: unknown command ‚convert‘

    Antworten ↓

  51. @dsp_ OK, das hat geholfen. Nun kommt was. Ich habe nur keine Zeit mehr zum Ausprobieren. Das muss wahrscheinlich bis zum Wochenende warten. :(

    @hukl: ich werde dann die Cygwin-Version ebenfalls mal am Wochenende probieren. Mal sehen wie dann die Zeilenenden im Repo aussehen. Hoffentlich gibt das kein Durcheinander.

    Wie kann ich eigentlich ein zentrales GIT repository anlegen und dann mein frisch erzeugtes lokalen Repo dort hinein pushen? Oder muss ich ein leeres Repo für das Projekt auf dem remote Repo anlegen. …Oh man klingt das komisch. Ich hoffe DU weißt was ich meine. ;-)

    Antworten ↓

  52. @joede unter git gibt es eine config variable core.autocrlf, die das handelt. Keine Ahnung wie gut das funktioniert unter cygwin. mercurial hat dafuer eine extension namens win32text. Aber auch da hab ich keine Erfahrung wie das gehandelt wird.

    Antworten ↓

  53. ich nehme an, ich werde auf den sack dafür bekommen… habe auch nicht alle kommentare gelesen… es geht ja auch eh nur um meinen meinung.

    ich brauche nicht immer eine lullibaba-leichte erklärung… und mir war es auch nicht zu technisch oder so. aber mir war es diesmal ein bisschen zu durcheinander – zumindest bis zur hälfte. how ever ist ja ein CHAOSradio … insofern passt es ja auch wieder. vielleicht lags auch daran, dass ich ausgerechnet zu dem thema gern mal richtig schön langsam abgeholt worden wäre.

    wie auch immer danke euch beiden.

    christian

    Antworten ↓

  56. Was mich besonders stört sind die Aussagen über Branching und Merging in CVS und SVN. Gerade beim Branching ist CVS aus meiner Sicht SVN deutlich überlegen *und* schneller und es sind auch nicht 20 Argumente sondern zwei. Nochmals. CVS ist nach heutigen Maßstäben schlecht, aber es ist nicht bei allem schlechter als SVN.

    Antworten ↓

  57. Ich bin noch nicht ganz durch mit Hören, aber ich werf einfach schonmal meine Anmerkungen in die Diskussion. Zunächst mal zu den hier genannten Punkten:

    Git unter Windows ist ein Krampf, es gibt nur den cygwin-Port und Git selbst scheint nicht auf Portabilität hin geschrieben zu sein. Wer DVCS unter Windows will, nimmt besser Mercurial und zwar am besten in der Form TortoiseHg. Da ist die Kommandozeilenversion gleich dabei (ohne cygwin) und es funktioniert out of the box problemlos. (Mercurial ist im Gegensatz zu Git in Python geschrieben, also OO, das kam ja hier auch zur Sprache.)

    Nächste Geschichte: zentrale Versionsverwaltungssysteme haben für bestimmte Projektstrukturen organisatorische Vorteile, die sich mit DVCS nicht abbilden lassen. Wenn es nur ein Repository gibt, zwinge ich die Nutzer, die Arbeit genau dort einzuchecken. Es gibt keine vergessenen Branches und niemand muss sich um das Einsammeln kümmern. Gerade in Firmen oder im Zusammenspiel mit unerfahrenen Nutzern ist das vorteilhaft.

    Den Single Point of Failure kann man im Fall von SVN abmildern, zumindest was Backups angeht. Für den Admin gibt es svnadmin dump und seit 1.4 kann jeder mit Lesezugriff das Repo mit svnsync clonen und auch aktuell halten. So mache ich persönlich von mehreren Projekten dezentrale Backups.

    Zur Größe der WC bei SVN: die WC ist ziemlich genau doppelt so groß wie die ausgecheckten Nutzerdateien. Da steht soweit ich weiß keine History drin, sondern nur einmal die komplette ausgecheckte Version. Lokale diffs zwischen geänderten Dateien und ausgecheckter Revision sind so möglich, für ältere Sachen muss ich’s vom Server holen. Das Repo selbst auf dem Server hingegen ist deutlich größer als bei Mercurial oder Git. Das ist korrekt.

    Dann zu Tags in SVN. Tags sind sozusagen »branches by convention«. Während ich bei Mercurial einer speziellen Revision einen sprechenden Namen annotiere, mache ich bei SVN ein svn cp (also einen Branch) und sage per Konvention, dass die Nutzer da nicht mehr drin rumfrickeln sollen. Die spezielle Behandlung von branches, tags und trunk in SVN wird zwar diskutiert, ist aber bis zur 1.6 nicht umgesetzt. Das sind normale Folder wie jeder andere auch im SVN und die Funktion ist nur durch die Nutzer per Konvention festgelegt.

    Soviel erstmal, ich hör dann später weiter…

    Antworten ↓

  58. @Sebastian Nunja, ich persönlich mag CVS generell nicht weil es technisch einfach so derart veraltet ist und derartig viele konzeptionelle Schwächen im Vergleich zu allen Späteren VCS hat. Das machte siche bisher auch immer bemerkbar. SVN ist in so vielen Bereichen besser als CVS das die Frage garnicht zu stellen lohnt ob man CVS oder SVN einsezten sollte. Es mag auch Workflows / Situationen geben die CVS garnicht so schlecht oder besser dastehen lassen aber die sollten in ihrer Anzahl stark limitiert sein. Ich kenne _niemanden_ der ernsthaft CVS noch benutzen will.

    Zum Branching. Aus meiner Sicht ist CVS beim Branchen genau garnicht überlegen. Im besten Fall ist es gleich schlecht wie in SVN. Ich persönlich finde es allerdings um einiges schlimmer als in SVN. Wie auch im Podcast erwähnt, ist Branchen an sich total irrelevant. Das Mergen ist am Ende das Wichtige. Hier noch mal ein kleiner Überblick wie das so in CVS funktioniert:

    http://www.astro.princeton.edu/~rhl/cvs-branches.html

    Das lässt die Konzptionellen Schwächen ganz klar erkennen. Nochmal. Es ging um DVCS und warum die so toll sind. Und wenn man sich git mercurial oder bazaar im vergleich zu CVS oder SVN anschaut kann man nur zu dem Schluss kommen, dass selbige nicht mehr zeitgemäß sind. Die Frage ob CVS oder SVN besser ist, war für uns eigentlich komplett irrelevant.

    Aber wie am Anfang schon erwähnt, im Vergleich zu CVS ist SVN schon gefühlte Dimensionen besser, technisch und konzeptionell!

    Antworten ↓

  59. Besten Dank für den hervorragenden und trotz seines Umfangs keineswegs zu langen Podcast, der mich von den Vorteilen eines VCS mehr als überzeugen konnte. Derzeit schubse ich meine Dateien ja nur mit Versionsnummern und in Ordnern mit Versionsnummern herum, was einerseits die Übersicht nimmt und andererseits völlig ineffizient ist. Ich habe es nur mit Markup (LaTeX) zu tun, nicht oder nur selten mit Code (wenn, dann Python). Deshalb noch eine Frage: Welches von den angesprochenen Systemen, Git oder Mercurial, wäre für die Verwaltung meiner LaTeX-Schriften mit Bibliographie etc. am sinnvollsten? Gibt es irgendwo im Netz eine Darstellung der Vorzüge und Nachteile, die die DVCSe im Umgang damit an den Tag legen? Hat jemand Erfahrungen mit der Verwaltung seiner Texte und vielleicht der Synchronisierung des ganzen Home-Verzeichnisses? Besten Dank im voraus für jeden Link/Hinweis. Grüße, Philipp

    Antworten ↓

  60. @Kapaneus: ich habe meine beiden großen Arbeiten im Studium mit LaTeX geschrieben und alles in einem Subversion-Repo gehabt. Gerade für das Einpflegen der Korrekturen war das Gold wert, weil man das genau in der Revision machen konnte, die man rausgegeben hatte und die fertige Korrektur dann einfach in den Hauptzweig gemergt hat, an dem man unterdessen weiter gearbeitet hatte. Wenn Du schon Erfahrung mit Subversion haben solltest, würde ich Mercurial empfehlen, da die Kommandos alle ähnlich sind. (Vereinfacht gesagt kommen nur push und pull dazu. ;-) ) Wenn Du portabel, also auf Windows, Linux und/oder OS X arbeiten musst, würde ich auch Mercurial nehmen. Git ist super flexibel und unheimlich mächtig, ich denke aber, dass der Einstieg in DVCS mit Mercurial leichter ist, auch weil das Command Set erstmal übersichtlicher ist und man sich meiner Meinung nach nicht so schnell selbst in den Fuß schießt. Da gibt’s ja dann auch noch das tolle (freie!) Buch: Mercurial: The Definitive Guide. *gg*

    Antworten ↓

  62. @LeSpocky geht das RCS-LaTeX-Paket eigentlich auch mit Mercurial / GIT?

    Kann ich so nicht beantworten. Ich hatte seinerzeit für Subversion bzw. SVK mit den Paketen svn-multi und svninfo gearbeitet, für andere VCS kann ich keine Aussagen machen.

    Diese Pakete lohnen sich ja im Grunde nur, wenn das VCS auch automatische Ersetzung von Keywords macht, d.h. beispielsweise aus $Revision$ automatisch beim Commit $Revision: 42$ macht. (Bei Subversion muss man das durch Setzen sogenannter Properties erst noch anfordern.)

    Ich hatte letztens mal für Mercurial geschaut, wie das dort umgesetzt wird. Dazu ist das Laden einer Extension notwendig, grundsätzlich also möglich: Keyword Extension – hab ich aber noch nicht ausprobiert. Für Git kann ich’s nicht sagen und ob es LaTeX-Pakete gibt, die das dann nutzen können auch nicht. Wenn Du das testest: am Ergebnis wäre ich interessiert. :-)

    Antworten ↓

  63. Schöne Folge. Ich wurde vor ca. einem Jahr von einem Kollegen auf git aufmerksam gemacht. Zu dem Zeitpunkt war das im Vergleich zu SVN war wir in der Firma verwenden wirklich ein sperriges, sprödes Teil. Genau so wie man es aus der Ecke aus der es kommt vermutet hätte. Ein Jahr später verwende ich zuhause git und bin erstaunt, wie in den Fehlermeldungen in menschenlesbarer Form zu lesen ist wo es klemmt und was zu tun ist.

    Github scheint ja wirklich ganz toll zu sein. Es ist kein Fehler, dass die gestaltungsaffinen Railsleute da mitmischen. Kaum auszudenken was geschehen würde wenn das bei Linux passiert.

    @panzi: Ich habe mich bewusst für git und gegen hg entschieden weil git in C geschrieben ist. Der laxe Umgang der Pythonwelt mit Schnittstellen und Kompatibilität hat mich schon genug genervt. Für ein Stück Software, das den Anspruch einer Infrastruktur hat, setze ich lieber auf Konstanz.

    Antworten ↓

  64. Um noch mal prähistorische Dinge aufzuwärmen:
    Die Versionierung bei VMS ist mit einem Semikolon (und nicht Komma) getrennt. Z.B. Datei.txt;2 -> beim erneuten Speichern gibt es dann ;3 und ;2. Es wird immer die höchste Nummer verwendet und mit purge liessen sich die alten Versionen löschen. Eigentlich ganz elegant für ein so altes System. Auch auf CDs (iso9669) lassen sich die Dateien mit Versionsnummer übrigens sichern, allerdings wird dies selbst bei Wikipedia inzwischen nicht mehr erwähnt. VMS scheint recht tot zu sein…

    Udo

    Antworten ↓

  66. @joede, @dsp_ core.autocrlf funktioniert soweit gut, sofern git die Files richtig als „text“ erkennt. Bei üblichen Filetypen ist das normalerweise der Fall, aber wenn man z.B. Sample-Files eincheckt, die auch auf Linux CRLF haben (z.B. vCards), dann wird es schwierig. Die muss man dann via .gitattributes extra ausnehmen (ab git 1.6.1.2).

    Anders als bei cvs ist das Attribut text (oder binary, oder unicode) kein Attribut des Repositories, sondern nur eine Prozedur die je nach (detektiertem oder per .gitattributes gesetztem) Filetype beim lesen/schreiben stur angewandt wird.

    CVS kann (weil es das text-flag im Repo hat) da flexibler sein – checkt man ein CRLF-File unter Linux ein, oder ein LF-only unter Windows, dann landen die immer normalisiert im Repo. Bei git werden mit gesetztem core.autocrlf beim Reinschreiben die CRs entfernt und beim Rausholen eingesetzt.

    Eine Rolle spielt das nur bei Setups wie ich eines hatte, wo Linux und Win sich ein gemeinsames working directory teilen. Je nach verwendetem Editor hatten die Files mal LF, mal CRLF. Das spielte auch keine Rolle, weil alle beteiligten Compiler mittlerweile beides verstehen, und CVS auch. Nach der Umstellung auf git ging das nicht mehr – ich verzichte jetzt einfach auf das gemeinsame working directory und habe für Win separat einen git clone, der per lokalem push/pull aktualisiert.

    Antworten ↓

  67. @LeSpocky das mit der Keyword Expansion wird schwierig. Das Modul fügt nämlich einen HASH anstelle der gezählten Revision ein. Ich habe in der spärlichen Doku nicht gefunden, dass mir erklärt, wie man diese numerische ID einfügt. Zudem werden die Keywords nur beim Archivieren oder beim explitziten „hg kwexpand“ ersetzt.

    Als Lösung für Makefiles (und C* Source) bietet sich der Aufruf von „hd id –num“ in Backticks an. Das könnte man dann für LaTeX nur nutzen, wenn man die gezählte Revision per sed im Text ersetzt.

    Antworten ↓

  68. Vielen Dank für die tollen Podcasts, insbesondere die technischen ;-)

    Ich fand es ein bisschen schade, dass als Alternative zu git fast nur immer von hg gesprochen wurde. Schade deswegen, weil bzr zwar erwähnt wurde, das aber im Vergleich zu hg sehr selten, obwohl so wie ich denke bzr durchaus sehr konkurrenzfähig sein dürfte. Ich versuche das deshalb hier mal auszugleichen ;-)

    Schaut einfach mal auf http://bazaar-vcs.org , da gibt es durchaus Statistiken wo bzr im Vergleich zu git und hg führt (z.B. http://bazaar-vcs.org/Benchmarks ->Disk Space Efficiency). Ich glaube, dass git und hg ohne der starken bzr -Konkurrenz nicht so stark wären wie sie es sind. Was Usability und technische Eigenschaften angeht dürfte bzr mehr als nur _noch_ so ein DVCS sein.

    Die Tatsache, dass bzr ausschließlich Python als direkte Abhängigkeit besitzt, macht z.B. einen Port auf Windows überflüssig. Die dadurch gesparten Ressourcen können in andere Dinge investiert werden.

    Ich persönlich bevorzuge bei DVCS Python vor C als Programmiersprache, weil die höhere Abstraktion und die Sprachfeatures mir meistens viel eher in Python-Code ermöglichen mich hineinzufinden als in C-Code.

    Bzr besitzt eine Plugin-API – git auch?

    Bzgl. aktiver Entwickler-Community: was LOC angeht ist momentan bzr vor git und hg führend (Quelle: http://ohloh.net). Natürlich weiß ich aber, dass eine hohe Anzahl an LOC nicht unbedingt bessere Software ergibt ;-)

    Abschließend meinerseits noch zwei kleine Hinweise:

    – Bzgl. pluggable merge: einach mal (bei vorhandener bzr-Installation) ‚bzr help merge‘ eingeben. Beim rumspielen und vergleichen (git vs. bzr) hatte ich mit git mal einen merge-Konflikt, den ich bei bzr nicht hatte (Vergleich jeweils mit Standard Merge-Algorithmus). Nachdem es im Beispiel nur eine direkt naheliegende Lösung gab, schloss ich daraus, dass bzr den Fall im Beispiel wohl besser löst.

    – bzr hat nicht nur eine pluggable merge API, das Storage-Format ist auch pluggable. Einfach mal ‚bzr help init eingeben‘.

    Viele Grüße
    Klaus

    Antworten ↓

  69. @joede klar, denn revisions ID sind nicht global, sondern nur lokal, deswegen verwendet die keyword extension die shas. Aber man sollte sowas *auf anfrage* auch gerne implementieren koennen.

    Antworten ↓

  70. @dsp_ jetzt wo Du es erwähnst. Ist ja auch irgendwo logisch. Naja, so einen Hash kann man aber nicht sinnvoll in LaTeX verarbeiten. Dann muss man sich was anderes überlegen. Ich hatte bisher immer die Revision von CVS als Revision des Textes. Das war eigentlich ganz nett. Naja, es geht aber auch ohne.

    Antworten ↓

  72. Hmm, cvs scheint mir ne gute möglichkeit meine dotfiles und latex-dokumente zu organisieren. was für ein cvs soll man nehmen, wenn man bloß alleine am pc die dotfiles organisiert? sollte man da ruhig sowas wie git/mercurial nehmen, oder wird das dann zu umständlich.

    und hat jemand sonst noch ideen zu latex-dokument wie man die schön mit einem cvs und vim kontrollieren kann?

    Antworten ↓

  73. @latex es kommt darauf an, was du willst. git/mercurial legen im Projektverzeichnis das Repository unter ./.git bzw. ./.hg an. Für LaTeX-Projekte ist das ja OK, aber für die dotfiles im Homeverzeichnis oder in /etc wäre mir das nichts. Für /etc nehme ich schon immer RCS. Das legt die History für ein einziges File direkt „danaben“ an. Für /etc/fstab wird dann /etc/fstab,v als History benutzt. Das finde ich persönlich für diesen Anwendungsfall ganz brauchbar. Du kannst natürlich auf das ganze /etc mit CVS/SVN oder sogar mit GIT/Mercurial verwalten. Nur was hat /etc/fstab z.B. mit /etc/resolv.conf zu tun. Nichts. Deswegen reicht mir RCS. Aber das ist Geschmackssache. ;-)

    Zum Thema GIT und LaTeX kann ich nur sagen, dass es mit GIT/Mercurial mindestens genauso gut klappt wie mit CVS/SVN. Nur das Ersetzen der Keyword geht halt nicht. Hier will ich mir ein Script basteln, dass mir vor dem Commit eines Release im Masterdokument die Revision erhöht. Das sollte reichen.

    Antworten ↓

  74. Pingback:   Automatische Keyword-Ersetzung mit Mercurial von antiblau blog

  75. @joede danke, ja ich glaub, dass das sinnvoll ist, dass ich rcs für die ganzen dotfiles benutzten werde, in der neusten ausgabe des archlinux magazins ist sogar ein artikel drin. ;)
    und für latex, hmm, ich probiere mal beides aus, wobei mir git/mercurial wohl die bessere lösung ist, falls man mal mit anderen zusammenarbeitet. danke für die entscheidungshilfe :)

    Antworten ↓

  77. Eine inhaltlich interessante Sendung – wenn ich auch die riesigen Probleme beim Mergen mit Subversion so nicht nachvollziehen kann.

    Sprachlich ist mit diesem Gespräch ein echter Tiefpunkt erreicht – das Zuhören war teilweise voller „pain“ und alles andere als „convenient“. Und das hatte nichts mit dem Wörtchen „genau“ zu tun…

    Antworten ↓

  78. Guter Podcast, das übliche Gemoser über die Sprecher kann ich nicht nachvollziehen.
    Gelernt hab ich das es RVS gibt, kannte ich noch nicht – klingt sehr nützlich. CVS hat mir mal ein Kumpel Anfang des Jahrtausends gezeigt, fand ich stark – aber jeder Versuch mich damit oder Subversion anzufreunden schlug fehl. Ich werde mal Git probieren, Github sieht sehr spannend aus.
    Was ich aber wirklich gern machen würde, ist PDFs versionieren. Ich zeichne große und komplexe Anlagen im Illustrator, zum einen wäre es spannend mal die Entwicklung einer Grafik nachverfolgen zu können und andererseits gibts auch im Nachhinein öfter mal Änderungen, Abzweigungen auch(unterschiedliche Endformate) – zusammenführen scheint mir bei Zeichnungen eher schwer möglich. Das Problem ist, das ich zu dem Thema einfach nichts finde.

    Antworten ↓

  79. Grosses Lob an Tim und an hukl – das war ein sehr guter Podcast. hukl hat genau das ruebergebracht, was mich auch vor 1,5 Jahren so fasziniert hat, um sofort auf Mercurial und spaeter auf git umzusteigen.

    Selbst fuer mich inzwischen sehr wichtige Features wie git rebase (History rewriten) habt ihr angesprochen. Vor allem interaktives rebase (git rebase -i) haben meine Arbeitsweise komplett veraendert – man hat praktisch volle Kontrolle ueber alles und kann komplett frei und ungleichmaessig committen, und spaeter trotzdem eine saubere Historie sicherstellen. Das sind so Features die man vorher nicht vermisst, weil man sie nicht kennt – heute nutze ich es taeglich.

    Ich denke DVCS haben mir, wie auch vielen anderen Leuten, die Augen geoeffnet und den Prozess der Versionierung zu etwas gemacht was Spass machen kann. Zu Zeiten von CVS oder SVN war es fuer mich auch immer eher eine Last und es wurde doch nur bei wirklich wichtigen Projekten gemacht. Heute mit einem DVCS wird sofort jedes Bastelprojekt versioniert, weil es so viel einfacher ist und Spass macht.

    Antworten ↓

  80. Super Thema, verständlich dargestellt und entspannt rübergebracht. Meine Frage zielt aber auf das Intro: Wer spricht da und wo lässt sich die komplette Rede nachhören/-lesen.

    Beste Grüße

    Antworten ↓

  81. Ein Zitat zum Thema soziale Aspekte:

    What is fascinating to me is how well some of the distributed version
    control technologies are geared towards allowing groups to have a shadow
    copy of a project. Maybe I should reword that as an „internal“ version
    of a project; it is actually a really good practice; offering a balance
    between „Sticking behind on a stable version“ vs the risk of „using the
    latest“. It really provides a programming team to control the software
    they are getting from the community at a different pace then the release
    cycle; it is also really good in that these teams can live and breath
    patches – and can hire you to fix problems.
    http://www.mail-archive.com/discuss@lists.osgeo.org/msg04310.html

    Antworten ↓

  82. Uns auf das praktischen Problem der „neuen“ Systemvielfalt wird hier verwiesen:
    Tortoise*

    Zitat:

    Today, DVCS is posh. So, an average developer who wants to contribute his cheap liberty to number of Open Source projects, will likely have to juggle clients to three or four kinds of the posh revision control systems.

    For Windows systems, we have the whole population of turtles on the land: TortoiseSVN, TortoiseGit, TortoiseBZR and TortoiseHg (hopefully, none of them are listed as endangered species). The stack of these turtles causes the context menu large enough to make it hard to use on small screens. Combinations of authorization systems, configuration files and mess with Putty and MinGW/MSYS dependencies…make participation in this whole libertinism ridiculously complex.

    Antworten ↓

  83. Es wurde im Podcast erwähnt, dass es möglich sei „alteingesessene“ Programmierer ihre gewohnte Schnittstelle zu bieten, ohne das sie merken, dass im Hintergrund ein Git-Backend rödelt.

    Das ganze habe ich bisher nur für CVS entdecken können (git-cvsserver). Gibt es eine Möglichkeit ein Subversionsprotokoll anzubieten, aber als Backend Git zu verwenden?
    Oder bleibt mir nur die Möglichkeit mit git-svn der Fremde in der Subversionwelt zu sein?

    Antworten ↓

  84. Pingback: Mehrwert: Versionsverwaltung mit Git | Karl Lorey

  86. So ich bin mal wieder hier am „ausgraben“. Coole Folge! Obwohl ich schon vor einigen Monaten auf git umgestiegen bin einiges neues gehört. Für alle die GUIs verwöhnt sind (also die „Windows-Jünger“) gibt es mit SourceTree ein cooles Interface (hat auch schon Bekannte Console-Verfechter überzeugt)

    lg wischi

    Antworten ↓

  87. Pingback: “Git” your work done and don´t mess with your team! | TIGER TECH TALK

  88. Heute die Folge noch mal gehört (was Seltenheitswert hat) und alles was vor 4 Jahren noch mehr als unverständlich war konnte ich beim heutigen hören verstehen und nachvollziehen :)

    Super Podcast danke nochmals.

    Antworten ↓

  89. Git und vor allem github.com ist wirklich ein Segen. Das schlimmste an SVN war/ist der zentrale Server. Für alles brauch man ne Verbindung zum Server und bei jedem Schritt kann ne Menge schiefgehen… SVN war immer eher ein Zwang: „Wir brauchen Versionierung (sonst fällt später alles außeinander), deshalb drücken wir uns jetzt das nervige SVN auf“. Bei git ist es eher: „Wenn ich git nehme, hab ich viel weniger Schmerzen bei der Entwicklung und hab automatisch noch ne Versionierung dabei *freu*“.

    Was garnicht angesprochen wurde ist, dass man bei github.com auch ein Issue-Tracker https://github.com/features#issues hat (sowas wie bugzilla). Der riesen Vorteil: man kann Pull-Requests zu einem Issue senden. Die Pull-Requests werden dann in der Diskussion zu dem Issue automatisch (chronologisch) eingepflegt. Es kommt sehr häufig vor, dass zu einem Issue mehrere Pull-Requests mit Diskussionen gibt, und erst ganz am Ende wird ein fix in den master eingepflegt wird.

    Es gibt inzwischen viele Open Source Projekte, die ihre komplette Entwicklung nur über github.com machen, ohne irgendwelche andere Tools. Die Einstiegshürde ist sehr niedrig (sowohl technisch, als auch sozial).

    Erwähnenswert ist noch gitflow http://nvie.com/posts/a-successful-git-branching-model/ Das ist ein Entwicklungsmodell (eine Sammlung von Konventionen) um mit git kollaborativ Software zu erstellen und weiterzuentwickeln.

    Wie hukl schon gesagt hat: Wenn man git einmal ausprobiert hat, will man nie wieder nach SVN zurück.

    Antworten ↓

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.