Verteilte Versionskontrolle mit Mercurial (DVCS)

Transkript

1 Verteilte Versionskontrolle mit Mercurial (DVCS) Peter Arrenbrecht (DVCS: distributed version control system)

2 DVCS ist heisses Thema Grosse Projekte haben umgestellt Mercurial: OpenJDK, Mozilla, Netbeans,... Git: Linux Kernel, X.org,... Bazaar: Ubuntu, Launchpad, MySQL,... und weitere sind daran, es zu tun Warum?

3 Versionskontrolle pfft, kennen wir doch Subversion, CVS, Perforce, jaja Eigene Arbeitskopie Aktueller Stand aus Archiv (checkout, update) Änderungen ins Archiv (checkin, commit) Schauen, was gelaufen ist (log, blame) etc.

4 Also so Arbeitskopie Server- Archiv edit status checkout update commit log blame braucht den Server

5 DVCS ist verteilt Jeder hat auch ein eigenes Archiv Commits sind erst mal lokal auch mehrere hintereinander auch offline Upload von Commits ist separate Aktion Download von fremden Commits auch

6 Nun also so lokales Archiv Arbeitskopie Server- Archiv edit status update commit log blame clone pull push alles lokal

7 Tempo, Tempo! Lokale Operationen sind Faktoren schneller als gegen den Server Schnelle Antwortzeit ist Usability! log, blame werden sinnvoll einsetzbar grep, bisect,... entstehen Sind auch offline verfügbar e mercurial/revlog.py hg blame mercurial/revlog.py grep hg grep --all mercurial

8 Branching bisher Wer darf überhaupt? Auch Versuchsballone für alle sichtbar Muss online sein Gewichtige Sache

9 Ad-Hoc Branching Arbeitskopie ist kurzlebiger Branch (darum muss update manchmal mergen) gut für Experimente, unterbrochene Arbeit in Subversion: einfach kopieren (auch offline, falls gleiche Basisversion) in Perforce? yuck! aber nur ein Commit tief

10 Also etwa so Arbeitskopie Arbeits- Server- Archiv kopie Arbeitskopie cp -r

11 DVCS ist branchy Jede Arbeitskopie hat eigenes Archiv Ideal für ad-hoc Branches leichtgewichtige lokale Kopie (hardlinks) anonym, wegwerfbar ohne Spuren mehrere Commits offline auf beliebiger Version aufsetzen

12 Also so lokales Archiv clone Archiv Arbeitskopie Server- Arbeitskopie lokales Archiv in dev-pbranch: hg clone.../temp hg outgoing hg incoming

13 Fördert gute Commits Kleine, fokussierte, schrittweise Commits einfacher für Reviewer bessere Nachvollziehbarkeit besser für bisect Erlaubt Korrekturen vor push dumme Tippfehler, vergessene Files

14 Oder auch so lokales Archiv Archiv Arbeitskopie Server- Arbeitskopie lokales Archiv Mitarbeiter an Konferenz hg bundle --all../pb.hg... hg unbundle../pb.hg

15 DVCS ist kommunikativ Commits können frei übertragen werden klassisch hierarchisch: Entwickler > Feature-Branch > Trunk > Golden ad-hoc vernetzt: im Team, auf Konferenzen, im Zug Commits übertragbar per http(s), ssh, share, , USB-Stick

16 Aber ohne Chaos! Überträgt immer nur fehlende Commits Merging ist explizit und kontrolliert Merges werden protokolliert und müssen nicht mehrfach gemacht werden Merging ist die natürlichste Sache der Welt! (Frei nach Torvalds: Why branch if you dare not merge? )

17 Vertrauenssache Commits werden mit SHA-1 identifiziert Umfasst Änderungen und SHA-1 der Basis- Version(en) Global eindeutig Kann als Build-ID dienen Kann signiert werden

18 Vereinfacht Reviews Reviewer erhält zu reviewende Commits per ad-hoc Austausch Reviewer setzt Wegwerf-Klon auf, importiert Commits, kann dann diffen, testen, etc. Entwickler kann auf Basis der Commits bereits weiterarbeiten Kann Review-Befunde kontrolliert einarbeiten hg id

19 So zum Beispiel r1 r2 r3 branch r4 merge r6 (anonym) r5 ad-hoc push r1 r2 Befund

20 Innovatives Branching daggy fixes Man korrigiert immer am Ursprung Kann damit ohne Backport in Release übernehmen pbranch - Branches zur Patchentwicklung Erlaubt Kollaboration auf Patches

21 DVCS ist flexibel Verschiedene Organisationsformen klassisch zentral hierarchisch vernetzt Einfache Pflege von lokalen Patches Einfache Backups und Mirrors

22 DVCS und FOSS Jeder kann klonen und branchen, ohne Committer-Rechte Nicht jeder kann pushen Committer-Modell (push) Maintainer-Modell (pull, , etc.) neue Maintainer für spezifische Aspekte können sich ad-hoc etablieren Beispiel TortoiseHg on Crew Linux-Kernel

23 Also nochmals Flexibel in der Organisation, speziell FOSS Ideal für Review-orientiertes Arbeiten Vertrauen dank kryptographischem Hashing Kontrolliertes Merging ohne Angst Fördert gute Commits Offline, schnell - und dadurch innovativ

24 Aber! Klon umfasst immer ganzes Archiv komplette Geschichte alle Verzeichnisse Unhandlich bei grossen Projekten! hohe Download-Zeiten Quota-Probleme Lese- und Schreibrechte global Siehe Jemmy innerhalb Netbeans FreeBSD

25 Und zudem! Häufiges Branchen und Mergen führt zu verzweigter Geschichte Datei-übergreifende Identifikation von Commits (Revisions) führt zu zusätzlichen Merges Kann bei hohem Push-Aufkommen zu Merge- Races führen Logs manchmal unübersichtlich in dev/hg/tmp-.../full-nb hg glog --limit 100 hg serve

26 Dann auch noch! Lokale Commits begünstigen Einsiedler Einfacher, Arbeit unfertig liegen bleiben zu lassen Speziell gefährlich bei Fronarbeit an FOSS- Projekten Erfordert mehr Verständnis für Source- Control-Konzepte

27 Was nun? Nicht ins Bockshorn jagen lassen! Viele grosse Projekte erfolgreich mit DVCS. Kleinere erst recht. Aber seriös prüfen, ob es passt.

28 Womit prüfen? Mercurial ;) schnell, kompakt, verständlich Plattform-übergreifend Git sehr schnell, gut mit Subversion nicht so gut mit Windows, sagt man Bazaar verständlich, gut mit Subversion kann Teile der Geschichte klonen

29 Featuring: Mercurial Einfacher Befehlssatz, ähnlich Subversion Trotzdem mächtig (mq) Gut dokumentiert (Online-Buch) Aktive, hilfreiche Community ( , IRC) Gut erweiterbar (Hooks, Extensions, Python) Aktives Team mit klarer Führung

30 Wo anfangen? Hauptsite mit Links zu Tutorials, Buch, Downloads, etc. Hier kann man Archive hosten lassen und zusammenarbeiten (ähnlich sf.net, code.google.com; gratis für FOSS) #mercurial auf freenode.net

31 Woran arbeiten wir? Noch bessere Zusammenarbeit mit Subversion Noch besseres Verhalten unter Windows Noch besseres TortoiseHg Klonen von Teilen der Geschichte und/oder Verzeichnisse Speed, speed, speed! Und vieles mehr

32 Woran arbeite ich? pbranch: Patch-Management als hierarchische Branches shallow clone: Klonen von nur neuerer Geschichte Deutsches Tutorial

33 Fragen? Gerne jetzt, falls wir noch Zeit haben Und auch gerne noch nach dem Vortrag!