Zwei Entwickler hat unser Testszenario, nehmen wir nun an, dass der zweite Entwickler „Bert“ sich nun gleich ans Werk macht und eine Änderung vornimmt. Er deutscht die Begrüßung ein und ändert “Hello Subversion” auf “Hallo Subversion”: (:Bild)

Der Befehl ‘svn status’ zeigt auf, dass die Datei verändert (’M’odifiziert) wurde: (:Bild)

Die Unterschiede der Datei zur geladenen Version lassen sich mit ‘svn diff’ aufzeigen. Hinzugefügte Zeilen beginnen mit eine “+”, Entfernte mit einem “-”: (:Bild)

Anschließend übermittelt er seine Änderungen an den Subversion-Server. (:Bild)

Auf dem Subversion-Server gilt nun die Revision 3 als Headversion. Bei einem Checkout ohne Revisionsangabe wird der Server nun Revision 3 übertragen. Sofern Subversion nicht mit dem Parameter –non-recursive (bzw. -N) gerufen wird, werden alle Änderungen an den Unterverzeichnisse übertragen. Höher liegende Verzeichnisse werden nicht beachtet. So kann man sich auch auf das Hochladen einzelner Unterverzeichnisse beschränken.

Auch Arne war nicht untätig, er legte eine neue Datei “person.h” an und verändert anschließend das Hauptprogramm, indem die Headerdatei nun eingebunden wird: (:Bild) (:Bild)

Anschließend fügt er die neue ‘person.h’ dem Repository hinzu und prüft mit Hilfe von „svn status“, ob alle Dateien im Repository liegen, welche Dateien verändert wurden und beim nächsten Commit auf dem Server aktualisiert werden. 

(:Bild)

Unser Entwickler hat das Projekt kompiliert und erfolgreich getestet, es sind alle Dateien im Repository angemeldet worden und er hat sich davon überzeugt (z.B. mittels svn diff), dass keine Datei eincheckt wird, die unnötige oder unpassende Änderungen besitzt (z.B. Debugausgaben). Also kann er die Änderungen nun auf den Server laden…

(:Bild)  …und stellt so fest, dass das nicht mehr möglich ist: Subversion verweigert das Aufspielen. Die Datei /trunk/main.c ist veraltet. Das liegt daran, dass Entwickler 2 zwischenzeitlich eine neue Version der Datei, die eingedeutschte Version, hochgeladen hat. Wir müssen also unsere Arbeitsversion erst auf den aktuellen Stand bringen und das geht mit dem Befehl ‘svn update’. (:Bild)

Die eigene Arbeitskopie wurde hiermit aktualisiert, das bedeutet, dass Subversion alle Änderungen vom Server abholt und versucht diese Änderungen auf Ihrem lokalen Rechner in Ihre Arbeitskopie einzufügen. Die Datei main.c konnte erfolgreich aus Revision 3 aus dem Repository und den eigenen Änderungen zusammengefügt werden. Das “G” in der Meldung steht für “merGed”. (:Bild)

Unsere lokale Kopie enthält also das selbstgeschriebene neue #include „person.h“, wie auch die von Bert eingedeutschte Fassung der Begrüßung. Nun ist die Arbeitskopie als hätten wir die auf dem Server aktuelle Revision 3 ausgecheckt und an dieser Revision 3 alle lokalen Änderungen gemacht. Bevor wir die Änderungen nun einchecken, sollten wir uns überzeugen, dass das Programm auch noch mit den Änderungen aus dem Repository zuverlässig läuft. Sollte uns dann kein anderer Entwickler zuvorkommen und eine neue Version hochladen, die von uns veränderte Dateien betrifft, so können wir nun unsere Änderungen auf den Subversion-Server übertragen:

(:Bild)