Brauche ich ein DVCS?

Transkript

1 Orientation in Objects GmbH Weinheimer Str Mannheim Kristian Köhler Steffen Schluff Version:.0 Gliederung Einleitung Grundbegriffe Workflows Demo Fazit 2

2 Gliederung Einleitung Grundbegriffe Workflows Demo Fazit 3 DVCS Historie (Auszug) Bazaar Mercurial Bit Keeper GNU arch Darcs Monotone Git

3 Unsere VCS Historie Repräsentativ für viele Entwickler, die Open Source Tools nutzen Kein Änderung war zwingend notwendig, aber wer einmal gewechselt hat, will nicht mehr zurück Git RCS CVS SVN Mercurial 5 Gliederung Einleitung Grundbegriffe Workflows Demo Fazit 6 3

4 Subversion und der einsame Entwickler SVN diff, cat, 7 DVCS und der einsame Entwickler DVCS diff, cat, 8 4

5 Der einsame Entwickler Kein paralleles Arbeiten mit anderen Kollegen Geringe Unterschiede zwischen SVN und DVCS im Befehlssatz Bei DVCS immer alles auf einem PC Setup für DVCS (argumentativ) leichter DVCS Repo lebt im Unterverzeichnis der 9 Subversion und viele Entwickler Central SVN update update update Carol s Clients / s 0 5

6 DVCS und viele Entwickler () Clients / s DVCS DVCS Carol s DVCS diff, cat, diff, cat, diff, cat, Carol s DVCS und viele Entwickler (2) Clients / s DVCS DVCS Carol s DVCS update update update Carol s 2 6

7 Viele Entwickler Jeder Entwickler hat eigenes DVCS Repo Daher Idee eines zusätzlichen zentralen DVCS Repos Zentrales DVCS Repo ähnlich zu SVN Ansatz Protokoll notwendig für Kommunikation zwischen DVCS Repos 3 In ein DVCS Projekt einsteigen () clone DVCS 4 7

8 In ein DVCS Projekt einsteigen (2) clone DVCS DVCS 5 In eigenem entwickeln DVCS DVCS 6 8

9 Änderungen an zentrales Repo übergeben 2 push DVCS DVCS 7 Änderungen aus zentralem Repo übernehmen 2 push 3 pull DVCS DVCS 8 9

10 Änderungen in eigene übernehmen 2 push 3 pull DVCS DVCS update 4 9 Changeset basiertes Arbeiten Eigener Befehlssatz für Abgleich zwischen DVCS Repos clone, push, pull, Abgleich basiert auf Änderungen nicht auf Dokumentversionen Es existiert per se keine verbindliche Dokumentversion In SVN implicit changeset : if you compare tree N with tree N Änderung (Changeset) ist der Unterschied zwischen zwei Versionen Änderungen in einem DVCS sind wie Overhead Folien Mehre übereinander gelegt ergeben ein Dokument Änderungen müssen eindeutig adressierbar sein Unterscheidung zwischen lokalen und globalen Namen 20 0

11 Zentralisiertes Arbeiten mit Revisionen Kohle + Bier Kohle Bier Kohle + Salat Bier + Fleisch Salat Kohle Bier Salat Fleisch r r2 r3 r4 Alice Bob Carol 2 Dezentrales Arbeiten mit Änderungen Kohle Central Kohle Bier Salat Fleisch + Bier + Salat Kohle c + Fleisch Kohle Alice c3 Carol + Bier c2 Kohle + Fleisch Bob c2 + Salat c + Salat + Bier 22

12 Viele Köche verderben den Brei Bisher wurde einfacher Fall ohne parallele Entwicklung betrachtet Nur ein Entwickler nimmt Änderungen vor und verteilt diese Was ist wenn mehrere Entwickler gleichzeitig ändern? D.h. mehrere Änderungen bezogen auf den gleichen Ausgangsstand Bei SVN führt dies zu einem Konflikt, der Merging benötigt Sonst können keine Änderungen mehr an das Repo übergeben werden 23 In eigenem entwickeln (again) DVCS DVCS

13 Beide Änderungen an zentrales Repo senden () 3 push DVCS DVCS 2 25 Beide Änderungen an zentrales Repo senden (2) 3 push 4 push DVCS DVCS

14 Zweite Änderung aus zentralem Repo übernehmen 3 push 4 pull DVCS DVCS 2 27 Änderungen mergen 3 push 4 pull DVCS DVCS 2 ci merge

15 Änderungen mergen und ten 3 push 4 pull DVCS DVCS 2 ci merge 5 ci 6 29 Merge an zentrales Repo senden 3 push 4 pull 7 push DVCS DVCS 2 ci merge 5 ci

16 ODER Änderungen (vorläufig) ignorieren 3 push 4 pull DVCS DVCS Konflikte und Branches Prämisse: Branches / mehrere Heads sind kein grosses Ding DVCS besitzen gut funktionierendes Mergetracking Branches können lokal leicht entstehen Explizites Branchen, Commit auf alte Version Branches können durch pull entstehen Vermengung eigener und fremder Changesets Änderungen / Branches landen im lokalen Repo nicht in der WC Branches sind aber nicht überall gewünscht In zentralem Repo eher nicht gewünscht Wer darf auf welchem Repo push und pull ausführen? 32 6

17 Gliederung Einleitung Grundbegriffe Workflows Demo Fazit 33 Subversion-Style Workflow Shared push/pull Clients / s 34 7

18 Integration Manager Workflow (Gatekeeper) push Integration Manager Public Public Public push Integration Manager push push 35 Dictator and Lieutenants Workflow Public Dictator Lieutenant Public Lieutenant Public Public Public Public Public 36 8

19 Kombinierte Workflows Central (Subversion) /update DVCS DVCS 37 Gliederung Einleitung Grundbegriffe Workflows Demo Fazit 38 9

20 Demo Demo DVCS 39 Gliederung Einleitung Grundbegriffe Workflows Demo Fazit 40 20

21 Fazit Flexiblere Workflows möglich aber nicht zwingend Auch in Kombination mit zentralem VCS Bessere Entwicklerkooperation und -isolation Branches und lokales Arbeiten Ad-hoc Zusammenarbeit und leichtes Merging Lernkurve nicht so steil wie befürchtet Toolunterstützung durch Drittanbieter ist erst im Entstehen Brauch ich es? - Nein, ich will es! 4 If you remember one thing Who the F*** cares? Use what YOU like, not what someone on the internet tells you to. ( 42 2

22 Mehr von OIO zum Thema... () Schulung: Versionsverwaltung mit Subversion Schulung: Versionsverwaltung mit CVS Vortrag OOP 2006: Subversion - Ein besseres CVS? Referenz: Open Source Support: Einsatzkonzept für Subversion 43 Mehr von OIO zum Thema... (2) Beratung zu Open Source Tools Referenz: Jumpstart: Webbasierte Informations- und Abrechnungsplattform im Gesundheitswesen Schulung zu Apache Ant und Maven

23 Ihr Sprecher Kristian Köhler Software-Architekt, Trainer, Berater Schwerpunkte Architekturen Java EE Backend Technologien 45 Ihr Sprecher Steffen Schluff Trainer, Berater, Entwickler Schwerpunkte Open Source Tooling Build Management Refactoring 46 23

24 ?? Fragen??? Orientation Objects GmbH Weinheimer Str Mannheim 47 Vielen Dank für ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim 24