This presentation was held on 19th of January 2015 to provide a brief use of SVN and Git in connection to project management techniques.
It is in German.
3. Software-Projektmanagement
Hochschule Reutlingen
Reutlingen University
3 Björn Kraus
Was ist Source Code Management bzw. Versionsverwaltung?
System zur Erfassung von Änderungen an Dokumenten oder Dateien,
oft auch zur Synchronisation unter beteiligten (zentraler & verteilter
Ansatz)
Jede Änderung wird mit einem Zeitstempel und einer
Benutzererkennung versehen und in einer Versionsgeschichte
gespeichert
Möglichkeit jede ältere Version wiederherzustellen bzw. Änderungen
rückgängig zu machen
Nicht nur für Source Code Verwaltung geeignet sondern auch
Beispielsweiße für normale Word Dokumente etc.
5. Software-Projektmanagement
Hochschule Reutlingen
Reutlingen University
5
Arten der Versionsverwaltung - Zentral
Klassische Client-Server Beziehung
Server beinhaltet das gemeinsame Repository
Zu bearbeitende Version wird dem Client als Arbeitskopie aus dem
Repository übermittelt
Änderung der Clients (Entwickler) an einer Version (meist an der
Aktuellsten) werden mittels Commit an den Server mitgeteilt und in die
entsprechende Version übernommen.
Andere Clients erhalten diese Änderungen bzw. die neuen Versionen
mittels Update in Ihrer Arbeitskopie
Björn Kraus
8. Software-Projektmanagement
Hochschule Reutlingen
Reutlingen University
8
Arten der Versionsverwaltung - Verteilte
Jeder Client verfügt über sein eigenes Repository
Jeder Commit eines Clients erfolgt zunächst nur lokal in seinem Repository.
Die dort getätigten Commits werden später per push an den Server übertragen
(Offizielles Repository)
Clients erhalten die für sie notwendigen Änderungen in dem sie sich mit den
Repositories anderer Clients abstimmen bzw. sich dieses Clonen
Zunächst keine Konflikte beim commiten, da dies erst lokal geschieht
Später werden Versionen der einzelnen Repositories überprüft und
zusammengeführt
Deutlich Flexibler als der Zentrale Ansatz, keine Verbindung zum Server
nötig für Commits, jedoch Komplexer und benötigt mehr
Koordiantionsaufwand
Björn Kraus
11. Software-Projektmanagement
Hochschule Reutlingen
Reutlingen University
Vorteile der Versionsverwaltung
Versionsgeschichte lässt genau nachvollziehen wer, wann, was
geändert hat
Änderungen können jeder Zeit rückgängig gemacht werden
Bietet die Möglichkeit zur Synchronisation, insbesondere für
verteiltes Programmieren
11
das Überschreiben einer Datei oder
fälschlicherweise vorgenommene Änderungen werden
verhindert bzw. können rückgängig gemacht werden
Björn Kraus
13. Software-Projektmanagement
Hochschule Reutlingen
Reutlingen University
13
Apache Software Foundation
1995: Gründung durch 8 Informatiker/Entwickler, darunter z.B. Brian
Behlendorf & Roy Fielding
Gründungsprojekt: Apache HTTP Server (Weiterentwicklung des
NCSA HTTPd Webservers)
1999: Umwandlung in die Apache Software Foundation & Gründung der
CollabNet Inc. durch Brian Behlendorf und O’Reilly Media
2000: Start der Entwicklung von Subversion bei CollabNet
2004: Release Version 1.0
2009: Wechsel des Projekts zur Apache Software Foundation
Dezember 2014: Release der Version 1.8.11
Björn Kraus
14. Software-Projektmanagement
Hochschule Reutlingen
Reutlingen University
14
Apache Software Foundation
Ehrenamtliche Organisation
450 Mitglieder & 3500 Entwickler
Aktuelle Top Level Projekte :
Apache HTTP Server
OpenOffice
Subversion
Hadoop (& Big Data)
….
Finanzierung durch Spenden & Sponsoren wie Google, IBM, Facebook usw.
Björn Kraus
Ok, ich begrusse euch alle zu unserem referat. Wir, ich Sven, und Bjorn, werden euch heute uber SCM und Microsoft in Sharepoint erzahlen.
Ubrings hat jemand mit diesen Verkzeugen schon irgendwie gearbeitet, entweder im Praktikum oder sonst?
Und dabei wie euch gleich Bjorn erzahlen wird, besteht SCM aus mehreren Komponenten, und wir warden uns heute hauptsahclich nur auf die Versionsverwaltung konzentrieren.
Als WiFo ist unsere Aufgabe oft die verschiedene Software Projekte zu managen oder auch weiter zuentwickeln. Dabei bei umfangreichen Projekten (aber auch naturlich bei den kleineren Projekten) ist es nicht mehr moglich den Quellcode uber Email oder Dropbox zu verwalten. Sie sind dafur gar nicht gut geignet und es ist auch nicht gewunscht.
Aus diesem Grund mochte man irgendwie unsere Arbeit als z.B. Programmieren vereinfachen und genau deswegen stellen wir stellen 2 konkterete Beispiele vor – Subversion und GIT
In zweiten Teil unsere PP wird euch danach Sven Microsoft Sharepoint vorstellen – namlich wie kann man Software Projekte durch SharePoint zu verwalten. Dabei geht er specizell auf PMOffice 365 was die name schon sagt, ist eine Projektnamangemengement losung.
Ubergabe des Worten an Bjorn.
System zur Erfassung von Änderungen an Dokummenten oder Dateien
Alle Versionen warden in einem Archiv bzw. Repository gespeichert zur wiederherstellung
Jede Änderung wird mit einem Zeitstempel und einer Benutzererkennung versehen
Ermöglicht jede Änderung zurückzuverfolgen: Wer hat wann was geändert
Möglichkeit Jede ältere Version wiederherzustellen bzw. Änderungen rückgängig zu machen
Nicht nur für Source Code Verwaltung geeignet sondern auch Beispielsweiße für Word Dokumente etc.
Bsp.: Autoren
Kommt jedoch häufig bzw. Überwiegend in Softwareprojekten zum Einsatz zur Verwaltung von Quellcode
Devops: QA people, Technology operations
Repository = Projektarchiv wo die einzelnen Versionen liegen, vergleichbar mit einer Datenbank.
Änderung der Clients (Entwickler) an einer Version (meist an der Aktuellsten) werden mittels Commit als neue Version in das gemeinsame Repository des Servers gelegt
Werden mehrer Commits gleichzeitig ausgeübt und diese betreffen die selbe textdatei, jedoch nicht die selbe zeile, werden die Commits automatisch zusammengefügt
Sind jedoch selbe identische Zeilen betroffen, so wird zumindest ein gegenseitiges überschreiben durch locks/sperren verhindert
In diesem Fall werden beide Versionen für sich im Repository abgelegt und es wird angezeigt das beide Dateien in Konflikt zueinander stehen.
Bevor ein Client ein update ausführt sollte er unbedingt seine Arbeiten mittels Commit speichern.
Zentrale Versionsverwaltung
Verteilte Versionsverwaltung
(Lokale Versionsverwaltung)
Eher für Einzelanwender oder kleine Gruppen innerhalb der selben Location
Hier wird oft nur eine einzige Datei versioniert, dies geschieht Lokal auf einem Rechner (Entwicklungsrechner)
Die verschieden Versionen der Datei warden Lokal auf dem Entwicklungsrechner gespeichert und sind nicht nach außen bzw. Rechner übergreifend verfügbar.
Kommt heute noch in Büroanwendungen vor, Beispielsweiße auch geeignet für Autoren.
General notes
https://projects.apache.org/indexes/pmc.html
General notes
https://projects.apache.org/indexes/pmc.html
Verteilte Versionsverwaltung
Andere Clients erhalten diese Änderungen in dem Sie das Offizielle Repository auf Ihren Rechner Clonen (pull)
Es werden nur die Datein geklont die verändert wurden bzw nicht vorhanden sind.
Später werden Versionen der einzelnen Repositorys überprüft und zusammengeführt
erfolgt in der Praxis häufig durch Personen mit Integrator-Rolle, hier endsteht der deutliche Mehraufwand an Koordination!
Deutlich Flexibler da Clients nur mit Repositorys abgleichen können die für sie Interressant sind und in Konflikt zueinander stehende Version unterschiedlicher Clients können zunächst paralle existieren, erst beim endgültigen zusammenführen muss geprüft warden, was Integratoren übernehmen! Clients arbeiten also deutlich Flexibler und unbeschwerter.
Mit entsprechender Versionskontrolle können viele übliche Probleme wie z.B.
General notes
https://projects.apache.org/indexes/pmc.html
Verzeichniss struktur (trunk, branch, tag)
Am beispiel von Wordpress
https://core.trac.wordpress.org/browser/
Created in 2000 by CollabNet Inc. with a goal to be CVS successor
Today it’s Apache Top-Level Project
Many good SVN clients such as:
TortoiseSVN for Windows Explorer Integration
Subclipse for Eclipse
AnkhSVN for Visual Studio
Used at some open source projects:
Wordpress.org
Webkit.org
…..
Hadoop und viele andere big data projekte
Unterschied zw. Mitglieder & Entwickler:
All software developed within the Foundation belongs to the ASF, and therefore the members. The members own the code and the direction of it and the Foundation. Committers get a shot at working on the code; good committers become members and thus get a piece of the ownership of the software and the direction.
OK, ich komme jetzt schon zu einem Verteiltem System – namens Git. Git wurde im Jahr 2005 von Linus Tor……. Fur die nutzung von Linux Kernel entwicklung entwickeldnt . Bickeeper hatte seine Licence geandert -> beinflussen wurde -> suchen -> iegenes entwickelt
Commit lokal, ohne Internet Zugang
Ist command line tool
Er bietet auch andere Mentatlitat -
Branches, tags, repository(-ies), security ….
Scalierbar bis auf tausende von Entwicklern
Schnell und effizient;Sauber Entwurf;Frei wie Freiheit
Für Projekte mit cca. 200 commits Mercurial ist schneller. http://draketo.de/proj/hg-vs-git-server/test-results.html
Branches sind “stable”; Trunk nur für Entwicklung
Trunk ist “stable”; Branches nur für Entwicklung
Review-System
Unterscheidung nach zentral und verteil und nach Kommerzionel und Frei,bzw. Open Source
Huete fast kostenfrei, vor einigen jahren um 500$$
Clear Case ab 2500 $$$
Perforce bis 20 free dann zahlen
git clone :Ein bestehendes Repository »klonen« oder »nachbilden« in ein neues Verzeichnis, und den aktuellen Branch holen
git pull :Zieht Änderungen von einem anderen Repository ins lokale Repository
git push :Schiebt Änderungen von einem lokalen Repository hoch zu einem anderen
Version 2 hat 146
Version 1 hatte uber 156
Git add . = alle datein
Keine gegenuberstellung
(Konzepte, Flexibilität….)
verfolgt
https://www.openhub.net/p/git
https://www.openhub.net/p/subversion
Aber github ist nicht einbezogen, wobei nur er hat uber 10 millionen repositories
SVN: 325 T
Git: 253 T
CVS: 63 T
u.a.: < 20 T
Sites such as Ohloh and Github only give you an indication of what's going on in the open source world, and take no account of the (much larger) commercial/industrial/closed source side of things;
April may 2014
Mercurial so cca. Bei 2-3 %
Projekt management wiki, bugzilla
Bevor ich schon weiter an Sven ubergebe, kurz noch zu Github.
Set to 150 %
Pro wiki a
https://github.com/Netflix/Hystrix
Pro zbytek
http://getbootstrap.com/css/
https://github.com/twbs/bootstrap
Firefox 16 Mil. +
It can reinforce natural communication since a DVCS makes this essential... in subversion what you have instead are commit races, which force communication, but by obstructing your work.
https://onedrive.live.com/view.aspx?cid=9E5CF9137FFDA246&resid=9E5CF9137FFDA246!14275&app=WordPdf
Unsere Losung
Verteilt = decentralliesiert
Perfore nutzen TOP Companies, aber ist $$$
Rest ist FOSS