Subversion: Unterschied zwischen den Versionen

(38 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)

Zeile 9:

* kurz: es ermöglicht mehreren Entwicklern komfortabler an einem Projekt gemeinsam und gleichzeitig zu arbeiten.

Wir verwenden [[Subversion]] im Sopra um genau diese Punkte zu ermöglichen. Jede [[Gruppeneinteilung|Gruppe]] erhält ihr eigenes [[#Repository|Repository]] und ~~hoffentlich (unsere Admins arbeiten daran)~~ auch ein [[Trac]], um ihr Projekt zu verwalten.

Wir verwenden [[Subversion]] im Sopra um genau diese Punkte zu ermöglichen. Jede [[Gruppeneinteilung|Gruppe]] erhält ihr eigenes [[#Repository|Repository]] und auch ein [[Trac]], um ihr Projekt zu verwalten.

[[Subversion]] besitzt eine Client-Server-[[Architektur]], sodass man neben dem Original-[[Subversion]]-Client<ref>[http://subversion.tigris.org/ offizielle Seite] des [[Subversion]]-Projekts</ref> auch einen beliebigen [[Subversion]]-[[#Clients|Client]] verwenden kann.

[[Subversion]] besitzt eine Client-Server-Architektur, sodass man neben dem Original-[[Subversion]]-Client<ref>[http://subversion.tigris.org/ offizielle Seite] des [[Subversion]]-Projekts</ref> auch einen beliebigen [[Subversion]]-[[#Clients|Client]] verwenden kann.

Grundsätzlich besteht eine [[Versionsverwaltung]] mit [[Subversion]] aus

* einem [[#Repository|Repository]] auf einem zentralen Server, das alle [[#Revision|Revisionen]] des Projekts enthält und

* vielen [[#Working Copy|Working Copies]] auf den Computern der Entwickler, die jeweils nur eine [[#Revision|Revision]] des Projekts zusammen mit den lokalen Änderungen des Entwicklers darstellen.

* vielen [[#Working Copy|Working Copies]] auf den Computern der Entwickler, die jeweils nur eine [[#Revision|Revision]] des Projekts zusammen mit den [[#Working Copy bearbeiten|lokalen Änderungen]] des Entwicklers darstellen.

== zentrale Begriffe ==

=== Revision ===

[[Image:revisions.png|thumb|right|~~200px~~|Der Repository-Browser von TortoiseSVN mit markierter Revisionsspalte]]

[[Image:revisions.png|thumb|right|400px|Der Repository-Browser von TortoiseSVN mit markierter Revisionsspalte]]

Eine ''Revision'' ist ein atomarer Zustand des [[#Repository|Repositorys]], der für jede Datei und jedes Verzeichnis einzeln gespeichert und durch eine fortlaufende Nummer ausgedrückt wird. Die aktuelle Revision (auch: Die ''Head''-Revision) eines [[#Repository|Repositorys]] ist dabei die durch die letzte Änderung des [[#Repository|Repositorys]] vergebene Zahl.

Jeder [[Subversion#Working Copy commiten|Commit]] eines Benutzers führt zu so einer Änderung am [[#Repository|Repository]] und erhöht die Revision um 1.

=== Repository ===

Zeile 29:

Zeile 30:

=== Working Copy ===

Die ''Working Copy'' (Arbeitskopie) ist ein Verzeichnis, das auf dem Rechner des Benutzers liegt und durch einen [[#Projekt auschecken|Checkout]] des [[#Repository|Repositorys]] angelegt wurde. Es enthält eine [[#Revision|Revision]] des [[#Repository|Repositorys]] zusammen mit den Änderungen, die der Benutzer daran vorgenommen hat. Diese Änderungen können durch einen [[#Working Copy commiten|Commit]] mit dem zentralen [[#Repository|Repository]] synchronisiert werden.

Die ''Working Copy'' (Arbeitskopie) ist ein Verzeichnis, das auf dem Rechner des Benutzers liegt und durch einen [[#Projekt auschecken|Checkout]] des [[#Repository|Repositorys]] angelegt wurde. Es enthält eine [[#Revision|Revision]] des [[#Repository|Repositorys]] zusammen mit den [[#Working Copy bearbeiten|lokalen Änderungen]], die der Benutzer daran vorgenommen hat. Diese Änderungen können durch einen [[#Working Copy commiten|Commit]] mit dem zentralen [[#Repository|Repository]] synchronisiert werden.

Die Working Copy kann durch ein [[#Working Copy updaten|Update]] auf den neuesten Stand (d.h. die neueste [[#Revision|Revision]]) gebracht werden. Dabei können [[#Conflicts|Konflikte]] entstehen.

Die Working Copy kann auch lokale Änderungen seit der letzen Synchronisation mit [[#Revert|Revert]] rückgängig machen. Das funktioniert nicht nur für die gesamte Working Copy, sondern auch für jede einzelne Datei in ihr.

Die Working Copy kann auch [[#Working Copy bearbeiten|lokale Änderungen]] seit der letzen Synchronisation mit [[#Revert|Revert]] rückgängig machen. Das funktioniert nicht nur für die gesamte Working Copy, sondern auch für jede einzelne Datei in ihr.

Mit [[#Projekt auschecken|Checkout]] und [[#Working Copy updaten|Update]] kann die Working Copy auch gezielt auf den Stand einer speziellen [[#Revision|Revision]] gebracht werden.

Zeile 39:

Zeile 40:

== Arbeiten mit Subversion ==

Wir beschreiben hier kurz und sehr abstrakt die einzelnen Funktionen, die ein [[Subversion]]-Client generell zur Verfügung stellt. Die genaue Funktionsweise kann von Client zu Client abweichen.

=== Projekt importieren ===

Mit ''Projekt importieren'' fügt man ein schon existierendes, nicht unter [[Versionsverwaltung]] stehendes, meist lokales, Verzeichnis zum [[#Repository|Repository]] hinzu.

'''Achtung:''' Das lokale, hinzugefügte Verzeichnis wird dadurch NICHT zur [[#Working Copy|Working Copy]]. Will man mit diesem Verzeichnis weiter arbeiten, muss man das [[#Repository|Repository]] [[#Projekt auschecken|auschecken]].

=== Projekt auschecken ===

Mit ''Projekt auschecken'' (<tt>SVN Checkout...</tt>) erzeugt man eine [[#Working Copy|Working Copy]] in einem lokalen, leeren Verzeichnis. Diese Funktion wird nur einmal im Leben einer [[#Working Copy|Working Copy]] verwendet.

'''Achtung:''' Auf keinen Fall einen [[#Projekt auschecken|Checkout]] in ein Verzeichnis machen, das bereits unter [[Versionsverwaltung]] steht.

=== Working Copy bearbeiten ===

Alle Dateien und Ordner in der [[#Working Copy|Working Copy]] können nahezu genauso bearbeitet werden, als wäre die [[#Working Copy|Working Copy]] ein normales Verzeichnis. Man kann Dateien und Verzeichnisse

Zeile 61:

Zeile 65:

=== Working Copy updaten ===

[[Image:update_messages.png|thumb|right|~~200px~~|Ein Update-Log mit typischen Status-Meldungen ([[TortoiseSVN]]).]]

Mit dem ''Update'' der [[#Working Copy|Working Copy]] (<tt>SVN Update</tt>) holt man sich die Änderungen der anderen Benutzer auf seinen Rechner. Dabei werden dem Benutzer die einzelnen Änderungen, die durch das Update an seiner [[#Working Copy|Working Copy]] vorgenommen wurden, in einem Update-Log angezeigt. Je nach [[#Clients|Client]] sieht das natürlich verschieden aus, aber die folgenden Aktionen wird man oft zu sehen bekommen<ref>Für eine vollständige Liste siehe http://knaddison.com/technology/svn-status-code-cheat-sheet</ref>:

<tr><th>Deleted</th><td>Die Datei wurde von einem anderen Benutzer in der Zwischenzeit gelöscht.</td></tr>

Zeile 71:

Zeile 76:

<tr><th>Merged</th><td>Seit dem letzen [[#Projekt auschecken|Checkout]] hat ein anderer Benutzer diese Datei geändert und sie wurde außerdem lokal geändert. In diesem Fall konnte [[Subversion]] die Änderungen automatisch zusammenführen (da z.B. der eine Benutzer nur den Anfang der Datei geändert hat, lokal aber nur das Ende geändert wurde)</td></tr>

</table>

=== Working Copy commiten ===

Wenn die [[#Working Copy bearbeiten|lokalen Änderungen]] (für den Moment) abgeschlossen sind, können sie ''commited'' werden. Dadurch werden sie in das [[#Repository|Repository]] eingefügt und den anderen Benutzern zur Verfügung gestellt.

Bei einem Commit sollte man auch immer eine Log-Message schreiben, sodass der Rest des Teams nachvollziehen kann, was (oder warum) man geändert hat. Sie sollten sich auf ein einheitliches Format (oder wenigstens eine Sprache) für diese Nachrichten einigen.

Sollte man beim Commit einen Fehler erhalten, kann dies mehrere Ursachen haben:

* Die [[#Working Copy|Working Copy]] hat eine ältere [[#Revision|Revision]] als das [[#Repository|Repository]]. Man sollte immer ein [[#Working Copy updaten|Update]] vor dem Commit ausführen.

* Die [[#Working Copy|Working Copy]] enthält unaufgelöste [[#Conflicts|Conflicts]].

Sollte der Commit durch ein unerwartetes Ereignis unterbrochen werden, z.B. durch einen Stromausfall oder den Verlust der Verbindung zum [[#Repository|Repository]], sperrt [[Subversion]] die [[#Working Copy|Working Copy]] und ignoriert diesen Commit im [[#Repository|Repository]], um inkonsistente Zustände zu vermeiden. In diesem Fall sollte vor einem erneuten Commit ein [[#Cleanup|Cleanup]] der [[#Working Copy|Working Copy]] durchgeführt werden.

'''Achtung''': NIEMALS [[#Working Copy bearbeiten|Änderungen]] einchecken, die das [[#Repository|Repository]] ''breaken''! Das sind [[#Working Copy bearbeiten|Änderungen]], die dazu führen, das das Projekt nicht mehr [[Compiler|kompiliert]]. Die anderen Team-Mitglieder können dann ohne ihre Hilfe nicht mehr weiterarbeiten (und werden entsprechend dankbar sein)!

=== Revert ===

Mit <code>svn revert</code> macht man alle lokalen Änderungen rückgängig. Dabei werden sowohl die Änderungen des Inhaltes wie auch an den Metadaten (Zeit, Rechte etc.) rückgängig gemacht. Mit <code>svn revert</code> kann auch die Markierung um neue Dateien oder Verzeichnisse Hinzufügen/Löschen wieder entfernt werden. Die Auswirkungen von <code>svn revert</code> sind dabei auf die Arbeitskopie beschränkt (Das Projekt-Archiv bleibt unberührt).

=== Ignore ===

Man kann die meisten [[Subversion]]-[[#Client|Clients]] anweisen, bestimmte Dateien in allen folgenden Operationen zu ignorieren, d.h. sie explizit nicht unter Versionskontrolle stellen.

Das ist insbesondere für temporäre Dateien (die z.B. bei jedem [[Build]] neu erzeugt werden) oder Benutzer-spezifische Einstellungen sinnvoll und muss von jedem verwendet werden.

Die folgenden Dateien und Verzeichnisse müssen auf jedenfall auf die Ignore-Liste und dürfen nicht mit eingecheckt werden:

<tr><td class="blank"></td><th>Warum?</th></tr>

<tr><th><tt>bin</tt></th><td>Die Dateien in diesem Ordner werden automatisch beim [[Compiler|Kompillieren]] erstellt, sie hochzuladen ist also unnötig. Zudem sind auch binäre Dateien dabei die sich beim kompilieren häufig ändern. Da binäre Dateien nicht gemerged werden können wird das zu häufigen Konflikten mit den Commits anderer Teammitglieder führen.</td></tr>

<tr><th><tt>obj</tt></th><td>Siehe <tt>bin</tt>.</td></tr>

<tr><th><tt>_ReSharper.#PROJEKTNAME#</tt></th><td>Dieses Verzeichnis wird vom Resharper automatisch generiert. Automatisch generierte Ordner sollen nicht ins SVN, siehe <tt>bin</tt>.</td></tr>

<tr><th><tt>*.suo</tt></th><td>Die Dateien mit der Endung .suo (''Solution User Options''<ref>[http://msdn.microsoft.com/en-us/library/bb165909(VS.80).aspx Solution User Options (.suo) in der MSDN]</ref>) beinhalten eine Reihe von Benutzer-spezifischen Einstellungen für [[VisualStudioTutorial|Visual Studio]], die niemanden außer den Benutzer selber interessieren. Sie enthalten außerdem eine Reihe von absoluten Pfadangaben, die bei anderen Benutzern massive Probleme auslösen können. Sie sollen auf keinen Fall zum [[#Repository|Repository]] [[#Working Copy commiten|hinzugefügt]] werden.</td></tr>

<tr><th><tt>*.cachefile</tt></th><td>Siehe <tt>bin</tt>. Auch merkt sich [[MonoGame]] hier, welche Dateien es schon in ein ihm genehmes Format konvertiert hat. Wenn ein anderes Teammitglied eine neue Datei hinzufügt und diese Datei im <tt>.cachefile</tt> als bereits konvertiert markiert ist, kann es passieren daß sich XNA denkt "Hey die Datei hab ich doch schon" und sie nicht neu konvertiert.</td></tr>

<tr><th><tt>*.DotSettings.user</tt></th><td>Diese Datei enthält Benutzerspezifische Resharper Einstellungen und soll entsprechend auch nicht eingecheckt werden.</td></tr>

<tr><th><tt>*.thumb</tt></th><td>Von Windows generierte Datei, die Vorschaubilder für die Miniaturansicht im Explorer enthält.</td></tr>

<tr><th><tt>thumbs.db</tt></th><td>Siehe .thumb</td></tr>

<tr><th><tt>.vs</tt></th><td>Von Visual Studio generiertes Verzeichnis für interne Einstellungen.</td></tr>

</table>

'''Hinweis:''' Bei Nutzung von [[Downloads#Subversion | TortoiseSVN]] als SVN Client müssen zuerst die Umgebenden Ordner eingecheckt werden damit die Ignore-Regeln gesetzt werden können! Also als erstes einfach das gesamte Projekt mit Ausnahme der zu ignorierenden Ordner und Dateien committen. Dann zu den zu ignorierenden Daten gehen und per Rechtsklick und Tortoise Menü auf die Ignore-Liste setzen (Das geht alternativ auch im Commit-Fenster). Sobald alle Ignore-Regeln gesetzt sind nocheinmal Committen damit die Ignore Regeln im SVN gespeichert sind.

Über die Kommandozeile fügt man Ordner/Dateien mittels <code>svn propset svn:ignore <Datei/Ordnername> .</code> hinzu. Oder man editiert die ignore Datei direkt mittels <code>svn propedit svn:ignore .</code> hier kann man durch newlines getrennt [http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13 pattern] für auszuschließende Objekte angeben

=== Diff ===

Mit ''Diff'' (in [[Subversion#TortoiseSVN|TortoiseSVN]] ''Show Modifications'') kann man sich die [[#Working Copy bearbeiten|Änderungen]], die man seit dem letzten [[#Projekt auschecken|Checkout]] gemacht hat, anzeigen lassen. Das ist insbesondere für das Erstellen der [[#Working Copy commiten|Commit]]-Log-Message nützlich (man weiss wieder, was man eigentlich gemacht hat).

=== Conflicts ===

=== ~~Blame~~ ===

Konflikte treten auf, wenn eine geänderte Datei committed wird, die in der Zwischenzeit in einer neueren Revision im Projekt-Archiv vorliegt. Konflikte bemerkt man entweder beim Committen <code>svn: Out of date</code> oder nach einem Update an der Markierung der Datei mit einem <code>C</code>.

Öffnet man die Datei sieht man die Konflikt behafteten Stellen:

<<<<<<< .mine

Das habe ich geschrieben

=======

Das steht in der letzten Revision im Projekt-Archiv (Hier Revision 42)

>>>>>>> .r42

Nach dem <code>svn update</code> sieht man jetzt 4 Versionen der betroffenen Datei <code>foo.cpp</code>

foo.cpp -> Die Datei mit den Markierungen wie oben.

foo.cpp.mine -> Die Datei mit nur meinen Änderungen.

foo.cpp.r41 -> Die Datei vor meinen Änderungen. (Also Revision 41 der Datei).

foo.cpp.r42 -> Die Datei mit nur den Änderungen aus dem Projekt-archiv. (Also Revision 42 der Datei).

Jetzt kann mann sich entscheiden

==== Letzte Revision im Projektarchiv verwenden ====

Hier werden meine Änderungen verworfen (das bedeutet '''alles was ich an der conflicted Datei geändert habe ist verloren''' und wird auch in keiner History gespeichert) und es wird die Letzte Revision aus dem Projekt-Archiv verwendet.

<code>svn resolve --accept theirs-full foo.cpp</code>.

==== Meine Änderungen verwenden und die Änderungen an der Letzten Revision(en) wegschmeißen ====

Eine Möglichkeit wäre: Man löscht die Datei <code>foo.cpp</code> nennt <code>foo.cpp.mine</code> in <code>foo.cpp</code> um. Jetzt muss man SVN mitteilen, dass der Konflikt behoben ist indem man <code>svn resolve foo.cpp</code> ausführt. SVN kümmert sich um die <code>foo.cpp.r<id></code> dateien. Das ganze geht auch mit einem Befehl: <code>svn resolve --accept mine-full foo.cpp</code>.

Jetzt sind in der aktuellen Revision nur meine Änderungen an der Datei. Alle Änderungen die in der Zwischenzeit vorgenommen wurden sind entfernt (allerdings noch in der History einsehbar).

==== Das beste aus Beiden Versionen behalten ====

Hier muss man die datei <code>foo.cpp</code> öffnen und alle Markierten Stellen von Hand bearbeiten, so dass am Ende das gewünschte übrig bleibt. Nach dem Speichern teilt man SVN mittels

<code>svn resolve foo.cpp</code> mit das nun alles in Ordnung ist. SVN kümmert sich (löscht) die verbleibenden Dateien und man kann jetzt committen. Um sich den Prozess der Bearbeitung zu erleichtern gibt es auch eine ganze reihe Tools und Plugins für fast alle gängigen Editoren.

[[Subversion#TortoiseSVN|TortoiseSVN]] bietet einen Merge-Editor an. Diesen startet man für eine conflicted Datei mittels Rechtsklick auf diese wählt dann ''"Edit conflicts"'' dies öffnet den Editor (siehe rechts). Hier ist die obere linke Hälfte die aktuelle Revision im Projekt-Archiv (Mit "Theirs" betitelt). Die rechte Hälfte (mit "Mine" betitelt) öffnet die <code>foo.cpp.mine</code> datei. In Orange ist jeweils die Differenz markiert (die Zeile dient zur Orientierung wie sie vor dem Konflikt war). Im unteren Editor kann man nun unter jeder orangen Zeile entscheiden, welchen Teil man übernehmen möchte. Mit Rechtsklick auf die Zeile wählt man für jede Differenz <code>Use text block from "theirs"</code> für den Code aus der aktuellen Revision im Projekt-Archiv oder <code>Use text block from "mine"</code> um den Code aus meinen Änderungen zu benutzen. Man kann auch etwas komplett anderes direkt in die Zeilen Schreiben.

Ist man mit der Bearbeitung fertig, klickt man oben links aus "Save". Jetzt sollte man schauen, ob die Datei auch wirklich so ist wie man sie möchte und ob das Projekt noch kompiliert etc. Dann kann man die Datei mit ''Rechtsklick -> TurtoiseSVN -> Resolve'' (Dies ist auch in der Taskleiste im MergeEditor möglich) als "resolved" markieren und committen.

=== History ===

=~~== Browse ===~~

Unter dieser Funktion versteht man die Überprüfung der Revisionsgeschichte (daher History) des [[#Repository|Repository]]. Dazu stehen verschiedene Werkzeuge zur Verfügung:

* ''List'' liefert eine Liste von Dateien/Verzeichnissen einer spezifischen [[#Revision|Revision]] des [[#Repository|Repositorys]] (in [[Subversion#TortoiseSVN|TortoiseSVN]] der ''Repo-Browser'', der über das Kontextmenü erreicht wird.)

* ''Log'' liefert alle Log-Messages einer Datei oder eines Verzeichnisses (''Show Log'' in [[Subversion#TortoiseSVN|TortoiseSVN]] (ebenfalls über das Kontextmenü) liefert alle Log-Messages von allen [[#Revision|Revisionen]])

* ''Cat'' gibt eine bestimmte Revision einer Datei auf den Bildschirm aus (in [[Subversion#TortoiseSVN|TortoiseSVN]] im Repo-Browser integriert)

* ''Blame'' zeigt eine Datei an und ordnet jede Zeile einem Benutzer zu, sodass man sehen kann, wer wann welche Änderungen vorgenommen hat.

=== Cleanup ===

Das ''Cleanup''-Kommando säubert [[Rekursion|rekursiv]] die [[#Working Copy|Working Copy]] indem es Locks<ref>Locks werden in diesem Artikel nicht behandelt, da wir glauben, das dieses Konzept überholt und - für uns - unnötig ist.</ref> entfernt und unterbrochene Operationen weiterführt (genauer: den Zustand so ändert, das er wieder konsistent ist).

== Clients ==

Zeile 89:

Zeile 178:

=== AnkhSVN ===

=== Web-Access ===

Unsere [[#Repository|Repositorys]] können auch ohne [[#Clients|Client]] über den Browser erreicht werden. Einfach den Pfad des [[#Repository|Repositorys]] (siehe [[Gruppeneinteilung]] oder [[#Sopra Repository|Abschnitt "Sopra Repository"]] für den eigenen Pfad) im Browser eingeben und mit den eigenen Zugangsdaten authentifizieren. Allerdings ist hierbei nur lesender Zugriff möglich.

== Sopra Repository ==

Um auf das [[Gruppeneinteilung|Gruppen]]-[[#Repository|Repository]] zuzugreifen, braucht man:

* einen IIF-Account (''Poolaccount'')

Der Pfad für das [[#Repository|Repository]] ist https://sotec.informatik.uni-freiburg.de/svn/sopraXX wobei das XX für die [[Gruppeneinteilung|Gruppennummer]] (01 bis 10) steht.

== Trac und SVN ==

Das Projektmanagement-Werkzeug Trac ist im Softwarepraktikum auch mit dem Versionskontrollsystem [[Subversion]] verbunden. Dies erlaubt nicht nur, das [[Subversion#History|Changelog]] über die Trac Weboberfläche einzusehen, sondern auch, Tickets über die [[Subversion#Working Copy commiten|Commit-Log-Messages]] zu referenzieren und zu schließen. Dabei wird die gesamte Log-Message eines Commits automatisch als Kommentar zu einem oder mehreren angegebenen Tickets hinzugefügt. Zusätzlich kann das entsprechende Ticket dabei auch geschlossen werden.

Dies ermöglicht eine bessere Nachvollziehbarkeit (Traceability) der Projektentwicklung durch die Zuordnung von Änderungen des Projekts zu einzelnen [[Item]]s im [[Product Backlog|Product-]] bzw. [[Sprint Backlog]].

=== Verwendung ===

Die Commit-Log-Messages werden nach Kommandos der Form <tt> [<Kommando> <Ticket> (<Konnektor> <Ticket>)*] </tt> durchsucht. Dabei stehen folgende Kommandos und Konnektoren zur Verfügung:

* Ticket schließen (dabei wird immer die in Trac eingestellte Default-Resolution verwendet) und referenzieren: <tt>close, closed, closes, fix, fixed, fixes</tt>

* Nur referenzieren: <tt>references, refs, addresses, re, see </tt>

* Remaining Time ändern: <tt>remaining <ticketid>:<hours></tt>

* Konnektoren: <tt>, & and</tt>

* Ticket-Schreibweise: <tt>ticket:<ticketid>, ticket<ticketid>, issue:<ticketid>, issue<ticketid>, bug:<ticketid>, bug<ticketid>, #<ticketid>, </tt>

=== Beispiele ===

Folgende Beispiele sind mögliche Commit-Log Messages:

Changed blah and foo to do this or that. [Fixes #10 and #12], and [refs #12].

This will [close #10 and #12].

Das betrifft [see #10, #12].

Ich habe an Ticket [see #13] weitergearbeitet. Die verbleibende Zeit ist nun [remaining #13:2h].

Die Kombination von Kommandos innerhalb einer Klammer ist allerdings nicht möglich. Folgendes Beispiel '''funktioniert nicht''':

Ich muss sowieso mal das zumachen: [close #30, #51 and refs #50]

Im Moment '''funktioniert nicht''', dass man die verbrauchte Zeit per Commit Message ändert. Bitte tragen Sie diese von Hand im Trac für Ihre Tasks nach, z.B. immer an einem festen Zeitpunkt in der Woche.

== siehe auch ==

Zeile 98:

Zeile 223:

* [http://www.cs.put.poznan.pl/csobaniec/Papers/svn-refcard.pdf Cheat-Sheet für Subversion]

[[Kategorie:~~Begriffe]]~~

[[Kategorie:Veraltet]]

~~[[Kategorie:Tutorials~~]]

Anonym

Suche

Subversion: Unterschied zwischen den Versionen

Namensräume

Mehr

Seitenaktionen

Navigation

Organisation

Ressourcen

Navigation

Wikiwerkzeuge

Wikiwerkzeuge

@@ Zeile 9: / Zeile 9: @@
 * kurz: es ermöglicht mehreren Entwicklern komfortabler an einem Projekt gemeinsam und gleichzeitig zu arbeiten.
-Wir verwenden [[Subversion]] im Sopra um genau diese Punkte zu ermöglichen. Jede [[Gruppeneinteilung|Gruppe]] erhält ihr eigenes [[#Repository|Repository]] und hoffentlich (unsere Admins arbeiten daran) auch ein [[Trac]], um ihr Projekt zu verwalten.
+Wir verwenden [[Subversion]] im Sopra um genau diese Punkte zu ermöglichen. Jede [[Gruppeneinteilung|Gruppe]] erhält ihr eigenes [[#Repository|Repository]] und auch ein [[Trac]], um ihr Projekt zu verwalten.
-[[Subversion]] besitzt eine Client-Server-[[Architektur]], sodass man neben dem Original-[[Subversion]]-Client<ref>[http://subversion.tigris.org/ offizielle Seite] des [[Subversion]]-Projekts</ref> auch einen beliebigen [[Subversion]]-[[#Clients|Client]] verwenden kann.
+[[Subversion]] besitzt eine Client-Server-Architektur, sodass man neben dem Original-[[Subversion]]-Client<ref>[http://subversion.tigris.org/ offizielle Seite] des [[Subversion]]-Projekts</ref> auch einen beliebigen [[Subversion]]-[[#Clients|Client]] verwenden kann.
 Grundsätzlich besteht eine [[Versionsverwaltung]] mit [[Subversion]] aus
 * einem [[#Repository|Repository]] auf einem zentralen Server, das alle [[#Revision|Revisionen]] des Projekts enthält und
-* vielen [[#Working Copy|Working Copies]] auf den Computern der Entwickler, die jeweils nur eine [[#Revision|Revision]] des Projekts zusammen mit den lokalen Änderungen des Entwicklers darstellen.
+* vielen [[#Working Copy|Working Copies]] auf den Computern der Entwickler, die jeweils nur eine [[#Revision|Revision]] des Projekts zusammen mit den [[#Working Copy bearbeiten|lokalen Änderungen]] des Entwicklers darstellen.
 == zentrale Begriffe ==
 === Revision ===
-[[Image:revisions.png|thumb|right|200px|Der Repository-Browser von TortoiseSVN mit markierter Revisionsspalte]]
+[[Image:revisions.png|thumb|right|400px|Der Repository-Browser von TortoiseSVN mit markierter Revisionsspalte]]
 Eine ''Revision'' ist ein atomarer Zustand des [[#Repository|Repositorys]], der für jede Datei und jedes Verzeichnis einzeln gespeichert und durch eine fortlaufende Nummer ausgedrückt wird. Die aktuelle Revision (auch: Die ''Head''-Revision) eines [[#Repository|Repositorys]] ist dabei die durch die letzte Änderung des [[#Repository|Repositorys]] vergebene Zahl.
 Jeder [[Subversion#Working Copy commiten|Commit]] eines Benutzers führt zu so einer Änderung am [[#Repository|Repository]] und erhöht die Revision um 1.
+<br clear="all">
 === Repository ===
@@ Zeile 29: / Zeile 30: @@
 === Working Copy ===
-Die ''Working Copy'' (Arbeitskopie) ist ein Verzeichnis, das auf dem Rechner des Benutzers liegt und durch einen [[#Projekt auschecken|Checkout]] des [[#Repository|Repositorys]] angelegt wurde. Es enthält eine [[#Revision|Revision]] des [[#Repository|Repositorys]] zusammen mit den Änderungen, die der Benutzer daran vorgenommen hat. Diese Änderungen können durch einen [[#Working Copy commiten|Commit]] mit dem zentralen [[#Repository|Repository]] synchronisiert werden.
+Die ''Working Copy'' (Arbeitskopie) ist ein Verzeichnis, das auf dem Rechner des Benutzers liegt und durch einen [[#Projekt auschecken|Checkout]] des [[#Repository|Repositorys]] angelegt wurde. Es enthält eine [[#Revision|Revision]] des [[#Repository|Repositorys]] zusammen mit den [[#Working Copy bearbeiten|lokalen Änderungen]], die der Benutzer daran vorgenommen hat. Diese Änderungen können durch einen [[#Working Copy commiten|Commit]] mit dem zentralen [[#Repository|Repository]] synchronisiert werden.
 Die Working Copy kann durch ein [[#Working Copy updaten|Update]] auf den neuesten Stand (d.h. die neueste [[#Revision|Revision]]) gebracht werden. Dabei können [[#Conflicts|Konflikte]] entstehen.
-Die Working Copy kann auch lokale Änderungen seit der letzen Synchronisation mit [[#Revert|Revert]] rückgängig machen. Das funktioniert nicht nur für die gesamte Working Copy, sondern auch für jede einzelne Datei in ihr.
+Die Working Copy kann auch [[#Working Copy bearbeiten|lokale Änderungen]] seit der letzen Synchronisation mit [[#Revert|Revert]] rückgängig machen. Das funktioniert nicht nur für die gesamte Working Copy, sondern auch für jede einzelne Datei in ihr.
 Mit [[#Projekt auschecken|Checkout]] und [[#Working Copy updaten|Update]] kann die Working Copy auch gezielt auf den Stand einer speziellen [[#Revision|Revision]] gebracht werden.
@@ Zeile 39: / Zeile 40: @@
 == Arbeiten mit Subversion ==
 Wir beschreiben hier kurz und sehr abstrakt die einzelnen Funktionen, die ein [[Subversion]]-Client generell zur Verfügung stellt. Die genaue Funktionsweise kann von Client zu Client abweichen.
 === Projekt importieren ===
 Mit ''Projekt importieren'' fügt man ein schon existierendes, nicht unter [[Versionsverwaltung]] stehendes, meist lokales, Verzeichnis zum [[#Repository|Repository]] hinzu.
 '''Achtung:''' Das lokale, hinzugefügte Verzeichnis wird dadurch NICHT zur [[#Working Copy|Working Copy]]. Will man mit diesem Verzeichnis weiter arbeiten, muss man das [[#Repository|Repository]] [[#Projekt auschecken|auschecken]].
 === Projekt auschecken ===
 Mit ''Projekt auschecken'' (<tt>SVN Checkout...</tt>) erzeugt man eine [[#Working Copy|Working Copy]] in einem lokalen, leeren Verzeichnis. Diese Funktion wird nur einmal im Leben einer [[#Working Copy|Working Copy]] verwendet.
 '''Achtung:''' Auf keinen Fall einen [[#Projekt auschecken|Checkout]] in ein Verzeichnis machen, das bereits unter [[Versionsverwaltung]] steht.
 === Working Copy bearbeiten ===
 Alle Dateien und Ordner in der [[#Working Copy|Working Copy]] können nahezu genauso bearbeitet werden, als wäre die [[#Working Copy|Working Copy]] ein normales Verzeichnis. Man kann Dateien und Verzeichnisse
@@ Zeile 61: / Zeile 65: @@
 === Working Copy updaten ===
-[[Image:update_messages.png|thumb|right|200px|Ein Update-Log mit typischen Status-Meldungen ([[TortoiseSVN]]).]]
+[[Image:update_messages.png|thumb|right|400px|Ein Update-Log mit typischen Status-Meldungen ([[Subversion#TortoiseSVN|TortoiseSVN]]).]]
 Mit dem ''Update'' der [[#Working Copy|Working Copy]] (<tt>SVN Update</tt>) holt man sich die Änderungen der anderen Benutzer auf seinen Rechner. Dabei werden dem Benutzer die einzelnen Änderungen, die durch das Update an seiner [[#Working Copy|Working Copy]] vorgenommen wurden, in einem Update-Log angezeigt. Je nach [[#Clients|Client]] sieht das natürlich verschieden aus, aber die folgenden Aktionen wird man oft zu sehen bekommen<ref>Für eine vollständige Liste siehe http://knaddison.com/technology/svn-status-code-cheat-sheet</ref>:
 <table class="default">
 <tr><th>Deleted</th><td>Die Datei wurde von einem anderen Benutzer in der Zwischenzeit gelöscht.</td></tr>
@@ Zeile 71: / Zeile 76: @@
 <tr><th>Merged</th><td>Seit dem letzen [[#Projekt auschecken|Checkout]] hat ein anderer Benutzer diese Datei geändert und sie wurde außerdem lokal geändert. In diesem Fall konnte [[Subversion]] die Änderungen automatisch zusammenführen (da z.B. der eine Benutzer nur den Anfang der Datei geändert hat, lokal aber nur das Ende geändert wurde)</td></tr>
 </table>
+<br clear="all">
 === Working Copy commiten ===
+Wenn die [[#Working Copy bearbeiten|lokalen Änderungen]] (für den Moment) abgeschlossen sind, können sie ''commited'' werden. Dadurch werden sie in das [[#Repository|Repository]] eingefügt und den anderen Benutzern zur Verfügung gestellt.
+Bei einem Commit sollte man auch immer eine Log-Message schreiben, sodass der Rest des Teams nachvollziehen kann, was (oder warum) man geändert hat. Sie sollten sich auf ein einheitliches Format (oder wenigstens eine Sprache) für diese Nachrichten einigen.
+Sollte man beim Commit einen Fehler erhalten, kann dies mehrere Ursachen haben:
+* Die [[#Working Copy|Working Copy]] hat eine ältere [[#Revision|Revision]] als das [[#Repository|Repository]]. Man sollte immer ein [[#Working Copy updaten|Update]] vor dem Commit ausführen.
+* Die [[#Working Copy|Working Copy]] enthält unaufgelöste [[#Conflicts|Conflicts]].
+Sollte der Commit durch ein unerwartetes Ereignis unterbrochen werden, z.B. durch einen Stromausfall oder den Verlust der Verbindung zum [[#Repository|Repository]], sperrt [[Subversion]] die [[#Working Copy|Working Copy]] und ignoriert diesen Commit im [[#Repository|Repository]], um inkonsistente Zustände zu vermeiden. In diesem Fall sollte vor einem erneuten Commit ein [[#Cleanup|Cleanup]] der [[#Working Copy|Working Copy]] durchgeführt werden.
+'''Achtung''': NIEMALS [[#Working Copy bearbeiten|Änderungen]] einchecken, die das [[#Repository|Repository]] ''breaken''! Das sind [[#Working Copy bearbeiten|Änderungen]], die dazu führen, das das Projekt nicht mehr [[Compiler|kompiliert]]. Die anderen Team-Mitglieder können dann ohne ihre Hilfe nicht mehr weiterarbeiten (und werden entsprechend dankbar sein)!
 === Revert ===
+Mit <code>svn revert</code> macht man alle lokalen Änderungen rückgängig. Dabei werden sowohl die Änderungen des Inhaltes wie auch an den Metadaten (Zeit, Rechte etc.) rückgängig gemacht. Mit <code>svn revert</code> kann auch die Markierung um neue Dateien oder Verzeichnisse Hinzufügen/Löschen wieder entfernt werden. Die Auswirkungen von <code>svn revert</code> sind dabei auf die Arbeitskopie beschränkt (Das Projekt-Archiv bleibt unberührt).
 === Ignore ===
+Man kann die meisten [[Subversion]]-[[#Client|Clients]] anweisen, bestimmte Dateien in allen folgenden Operationen zu ignorieren, d.h. sie explizit nicht unter Versionskontrolle stellen.
+Das ist insbesondere für temporäre Dateien (die z.B. bei jedem [[Build]] neu erzeugt werden) oder Benutzer-spezifische Einstellungen sinnvoll und muss von jedem verwendet werden.
+Die folgenden Dateien und Verzeichnisse müssen auf jedenfall auf die Ignore-Liste und dürfen nicht mit eingecheckt werden:
+<table class="default">
+<tr><td class="blank"></td><th>Warum?</th></tr>
+<tr><th><tt>bin</tt></th><td>Die Dateien in diesem Ordner werden automatisch beim [[Compiler|Kompillieren]] erstellt, sie hochzuladen ist also unnötig. Zudem sind auch binäre Dateien dabei die sich beim kompilieren häufig ändern. Da binäre Dateien nicht gemerged werden können wird das zu häufigen Konflikten mit den Commits anderer Teammitglieder führen.</td></tr>
+<tr><th><tt>obj</tt></th><td>Siehe <tt>bin</tt>.</td></tr>
+<tr><th><tt>_ReSharper.#PROJEKTNAME#</tt></th><td>Dieses Verzeichnis wird vom Resharper automatisch generiert. Automatisch generierte Ordner sollen nicht ins SVN, siehe <tt>bin</tt>.</td></tr>
+<tr><th><tt>*.suo</tt></th><td>Die Dateien mit der Endung .suo (''Solution User Options''<ref>[http://msdn.microsoft.com/en-us/library/bb165909(VS.80).aspx Solution User Options (.suo) in der MSDN]</ref>) beinhalten eine Reihe von Benutzer-spezifischen Einstellungen für [[VisualStudioTutorial|Visual Studio]], die niemanden außer den Benutzer selber interessieren. Sie enthalten außerdem eine Reihe von absoluten Pfadangaben, die bei anderen Benutzern massive Probleme auslösen können. Sie sollen auf keinen Fall zum [[#Repository|Repository]] [[#Working Copy commiten|hinzugefügt]] werden.</td></tr>
+<tr><th><tt>*.cachefile</tt></th><td>Siehe <tt>bin</tt>. Auch merkt sich [[MonoGame]] hier, welche Dateien es schon in ein ihm genehmes Format konvertiert hat. Wenn ein anderes Teammitglied eine neue Datei hinzufügt und diese Datei im <tt>.cachefile</tt> als bereits konvertiert markiert ist, kann es passieren daß sich XNA denkt "Hey die Datei hab ich doch schon" und sie nicht neu konvertiert.</td></tr>
+<tr><th><tt>*.DotSettings.user</tt></th><td>Diese Datei enthält Benutzerspezifische Resharper Einstellungen und soll entsprechend auch nicht eingecheckt werden.</td></tr>
+<tr><th><tt>*.thumb</tt></th><td>Von Windows generierte Datei, die Vorschaubilder für die Miniaturansicht im Explorer enthält.</td></tr>
+<tr><th><tt>thumbs.db</tt></th><td>Siehe .thumb</td></tr>
+<tr><th><tt>.vs</tt></th><td>Von Visual Studio generiertes Verzeichnis für interne Einstellungen.</td></tr>
+</table>
+'''Hinweis:''' Bei Nutzung von [[Downloads#Subversion | TortoiseSVN]] als SVN Client müssen zuerst die Umgebenden Ordner eingecheckt werden damit die Ignore-Regeln gesetzt werden können! Also als erstes einfach das gesamte Projekt mit Ausnahme der zu ignorierenden Ordner und Dateien committen. Dann zu den zu ignorierenden Daten gehen und per Rechtsklick und Tortoise Menü auf die Ignore-Liste setzen (Das geht alternativ auch im Commit-Fenster). Sobald alle Ignore-Regeln gesetzt sind nocheinmal Committen damit die Ignore Regeln im SVN gespeichert sind.
+Über die Kommandozeile fügt man Ordner/Dateien mittels <code>svn propset svn:ignore <Datei/Ordnername> .</code> hinzu. Oder man editiert die ignore Datei direkt mittels <code>svn propedit svn:ignore .</code> hier kann man durch newlines getrennt [http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13 pattern] für auszuschließende Objekte angeben
 === Diff ===
+Mit ''Diff'' (in [[Subversion#TortoiseSVN|TortoiseSVN]] ''Show Modifications'') kann man sich die [[#Working Copy bearbeiten|Änderungen]], die man seit dem letzten [[#Projekt auschecken|Checkout]] gemacht hat, anzeigen lassen. Das ist insbesondere für das Erstellen der [[#Working Copy commiten|Commit]]-Log-Message nützlich (man weiss wieder, was man eigentlich gemacht hat).
 === Conflicts ===
-=== Blame ===
+[[Image:TortoiseSVN_commit_failed.png|thumb|right|300px|[[Subversion#TortoiseSVN|TortoiseSVN]] Dialog: Commit schlägt fehl, da <code>foo.cpp</code> in neuerer Revision vorliegt]]
+Konflikte treten auf, wenn eine geänderte Datei committed wird, die in der Zwischenzeit in einer neueren Revision im Projekt-Archiv vorliegt. Konflikte bemerkt man entweder beim Committen <code>svn: Out of date</code> oder nach einem Update an der Markierung der Datei mit einem <code>C</code>.
+Öffnet man die Datei sieht man die Konflikt behafteten Stellen:
+ <<<<<<< .mine
+ Das habe ich geschrieben
+ =======
+ Das steht in der letzten Revision im Projekt-Archiv (Hier Revision 42)
+ >>>>>>> .r42
+Nach dem <code>svn update</code> sieht man jetzt 4 Versionen der betroffenen Datei <code>foo.cpp</code>
+ foo.cpp      -> Die Datei mit den Markierungen wie oben.
+ foo.cpp.mine -> Die Datei mit nur meinen Änderungen.
+ foo.cpp.r41  -> Die Datei vor meinen Änderungen. (Also Revision 41 der Datei).
+ foo.cpp.r42  -> Die Datei mit nur den Änderungen aus dem Projekt-archiv. (Also Revision 42 der Datei).
+Jetzt kann mann sich entscheiden
+==== Letzte Revision im Projektarchiv verwenden ====
+Hier werden meine Änderungen verworfen (das bedeutet '''alles was ich an der conflicted Datei geändert habe ist verloren''' und wird auch in keiner History gespeichert) und es wird die Letzte Revision aus dem Projekt-Archiv verwendet.
+<code>svn resolve --accept theirs-full foo.cpp</code>.
+==== Meine Änderungen verwenden und die Änderungen an der Letzten Revision(en) wegschmeißen ====
+Eine Möglichkeit wäre: Man löscht die Datei <code>foo.cpp</code> nennt <code>foo.cpp.mine</code> in <code>foo.cpp</code> um. Jetzt muss man SVN mitteilen, dass der Konflikt behoben ist indem man <code>svn resolve foo.cpp</code> ausführt. SVN kümmert sich um die <code>foo.cpp.r<id></code> dateien. Das ganze geht auch mit einem Befehl: <code>svn resolve --accept mine-full foo.cpp</code>.
+Jetzt sind in der aktuellen Revision nur meine Änderungen an der Datei. Alle Änderungen die in der Zwischenzeit vorgenommen wurden sind entfernt (allerdings noch in der History einsehbar).
+==== Das beste aus Beiden Versionen behalten ====
+[[Image:TortoiseMerge.png|thumb|right|300px|[[Subversion#TortoiseSVN|TortoiseSVN]] Merge tool]]
+Hier muss man die datei <code>foo.cpp</code> öffnen und alle Markierten Stellen von Hand bearbeiten, so dass am Ende das gewünschte übrig bleibt. Nach dem Speichern teilt man SVN mittels
+<code>svn resolve foo.cpp</code> mit das nun alles in Ordnung ist. SVN kümmert sich (löscht) die verbleibenden Dateien und man kann jetzt committen. Um sich den Prozess der Bearbeitung zu erleichtern gibt es auch eine ganze reihe Tools und Plugins für fast alle gängigen Editoren.
+[[Subversion#TortoiseSVN|TortoiseSVN]] bietet einen Merge-Editor an. Diesen startet man für eine conflicted Datei mittels Rechtsklick auf diese wählt dann ''"Edit conflicts"'' dies öffnet den Editor (siehe rechts). Hier ist die obere linke Hälfte die aktuelle Revision im Projekt-Archiv (Mit "Theirs" betitelt). Die rechte Hälfte (mit "Mine" betitelt) öffnet die <code>foo.cpp.mine</code> datei. In Orange ist jeweils die Differenz markiert (die Zeile dient zur Orientierung wie sie vor dem Konflikt war). Im unteren Editor kann man nun unter jeder orangen Zeile entscheiden, welchen Teil man übernehmen möchte. Mit Rechtsklick auf die Zeile wählt man für jede Differenz <code>Use text block from "theirs"</code> für den Code aus der aktuellen Revision im Projekt-Archiv oder <code>Use text block from "mine"</code> um den Code aus meinen Änderungen zu benutzen. Man kann auch etwas komplett anderes direkt in die Zeilen Schreiben.
+Ist man mit der Bearbeitung fertig, klickt man oben links aus "Save". Jetzt sollte man schauen, ob die Datei auch wirklich so ist wie man sie möchte und ob das Projekt noch kompiliert etc. Dann kann man die Datei mit ''Rechtsklick -> TurtoiseSVN -> Resolve'' (Dies ist auch in der Taskleiste im MergeEditor möglich) als "resolved" markieren und committen.
 === History ===
-=== Browse ===
+[[Image:log_messages.png|thumb|right|400px|Die ''Show Log'' Ansicht von [[Subversion#TortoiseSVN|TortoiseSVN]]]]
+Unter dieser Funktion versteht man die Überprüfung der Revisionsgeschichte (daher History) des [[#Repository|Repository]]. Dazu stehen verschiedene Werkzeuge zur Verfügung:
+* ''List'' liefert eine Liste von Dateien/Verzeichnissen einer spezifischen [[#Revision|Revision]] des [[#Repository|Repositorys]] (in [[Subversion#TortoiseSVN|TortoiseSVN]] der ''Repo-Browser'', der über das Kontextmenü erreicht wird.)
+* ''Log'' liefert alle Log-Messages einer Datei oder eines Verzeichnisses (''Show Log'' in [[Subversion#TortoiseSVN|TortoiseSVN]] (ebenfalls über das Kontextmenü) liefert alle Log-Messages von allen [[#Revision|Revisionen]])
+* ''Cat'' gibt eine bestimmte Revision einer Datei auf den Bildschirm aus (in [[Subversion#TortoiseSVN|TortoiseSVN]] im Repo-Browser integriert)
+* ''Blame'' zeigt eine Datei an und ordnet jede Zeile einem Benutzer zu, sodass man sehen kann, wer wann welche Änderungen vorgenommen hat.
+<br clear="all">
+=== Cleanup ===
+Das ''Cleanup''-Kommando säubert [[Rekursion|rekursiv]] die [[#Working Copy|Working Copy]] indem  es Locks<ref>Locks werden in diesem Artikel nicht behandelt, da wir glauben, das dieses Konzept überholt und - für uns - unnötig ist.</ref> entfernt und unterbrochene Operationen weiterführt (genauer: den Zustand so ändert, das er wieder konsistent ist).
 == Clients ==
@@ Zeile 89: / Zeile 178: @@
 === AnkhSVN ===
 {{:AnkhSVN}}
+=== Web-Access ===
+Unsere [[#Repository|Repositorys]] können auch ohne [[#Clients|Client]] über den Browser erreicht werden. Einfach den Pfad des [[#Repository|Repositorys]] (siehe [[Gruppeneinteilung]] oder [[#Sopra Repository|Abschnitt "Sopra Repository"]] für den eigenen Pfad) im Browser eingeben und mit den eigenen Zugangsdaten authentifizieren. Allerdings ist hierbei nur lesender Zugriff möglich.
+== Sopra Repository ==
+Um auf das [[Gruppeneinteilung|Gruppen]]-[[#Repository|Repository]] zuzugreifen, braucht man:
+* einen IIF-Account (''Poolaccount'')
+<!--* ein WWW-Passwort (das man [https://support.informatik.uni-freiburg.de/cgi/support/fawmgr.cgi?wpassword:de hier] einrichten kann)-->
+Der Pfad für das [[#Repository|Repository]] ist https://sotec.informatik.uni-freiburg.de/svn/sopraXX wobei das XX für die [[Gruppeneinteilung|Gruppennummer]] (01 bis 10) steht.
+== Trac und SVN ==
+Das Projektmanagement-Werkzeug Trac ist im Softwarepraktikum auch mit dem Versionskontrollsystem [[Subversion]] verbunden. Dies erlaubt nicht nur, das [[Subversion#History|Changelog]] über die Trac Weboberfläche einzusehen, sondern auch, Tickets über die [[Subversion#Working Copy commiten|Commit-Log-Messages]] zu referenzieren und zu schließen. Dabei wird die gesamte Log-Message eines Commits automatisch als Kommentar zu einem oder mehreren angegebenen Tickets hinzugefügt. Zusätzlich kann das entsprechende Ticket dabei auch geschlossen werden.
+Dies ermöglicht eine bessere Nachvollziehbarkeit (Traceability) der Projektentwicklung durch die Zuordnung von Änderungen des Projekts zu einzelnen [[Item]]s im [[Product Backlog|Product-]] bzw. [[Sprint Backlog]].
+=== Verwendung ===
+Die Commit-Log-Messages werden nach Kommandos der Form <tt> [<Kommando> <Ticket> (<Konnektor> <Ticket>)*] </tt> durchsucht. Dabei stehen folgende Kommandos und Konnektoren zur Verfügung:
+* Ticket schließen (dabei wird immer die in Trac eingestellte Default-Resolution verwendet) und referenzieren: <tt>close, closed, closes, fix, fixed, fixes</tt>
+* Nur referenzieren: <tt>references, refs, addresses, re, see </tt>
+* Remaining Time ändern: <tt>remaining <ticketid>:<hours></tt>
+* Konnektoren: <tt>, & and</tt>
+* Ticket-Schreibweise: <tt>ticket:<ticketid>, ticket<ticketid>, issue:<ticketid>, issue<ticketid>, bug:<ticketid>, bug<ticketid>, #<ticketid>, </tt>
+=== Beispiele ===
+Folgende Beispiele sind mögliche Commit-Log Messages:
+ Changed blah and foo to do this or that. [Fixes #10 and #12], and [refs #12].
+ This will [close #10 and #12].
+ Das betrifft [see #10, #12].
+ Ich habe an Ticket [see #13] weitergearbeitet. Die verbleibende Zeit ist nun [remaining #13:2h].
+Die Kombination von Kommandos innerhalb einer Klammer ist allerdings nicht möglich. Folgendes Beispiel '''funktioniert nicht''':
+ Ich muss sowieso mal das zumachen: [close #30, #51 and refs #50]
+Im Moment '''funktioniert nicht''', dass man die verbrauchte Zeit per Commit Message ändert. Bitte tragen Sie diese von Hand im Trac für Ihre Tasks nach, z.B. immer an einem festen Zeitpunkt in der Woche.
 == siehe auch ==
@@ Zeile 98: / Zeile 223: @@
 * [http://www.cs.put.poznan.pl/csobaniec/Papers/svn-refcard.pdf Cheat-Sheet für Subversion]
-[[Kategorie:Begriffe]]
+[[Kategorie:Veraltet]]
-[[Kategorie:Tutorials]]

Anonym

Suche

Subversion: Unterschied zwischen den Versionen

Navigation

Wikiwerkzeuge

Seitenwerkzeuge