Trac & Subversion
Schon mehrmals haben wir über eine elegante Lösung zum Schließen der Lücke zwischen CVS und unserem Tickektsystem nachgedacht. Die Idee ist einfach: auf irgendeinem Weg muss das CVS Commit mit einem Ticket verknüpft werden können.
Grundsätzlich gibt es zwei Möglichkeiten, wenn man eine dritte Datenquelle vermeiden möchte: (1) das Speichern der jeweiligen Ticketnummer im CVS Commit oder ein Vermerk der Ressourcen und Ihrer Versionen von CVS im Ticket.
Da man als Entwickler zunächst in einer IDE wie z.B. Eclipse arbeitet, wäre eine Integration der Ticketinformationen in die Version-Kommentare vorzuziehen. Zudem hat dieser Weg den Vorteil, dass die Veränderungen am Code auch wirklich als Versionskommentare gepflegt werden, wo diese auch hingehören.
Nun bin ich erneut über Trac gestoßen, und zwar, weil es eine Subversion Schnittstelle anbietet. Eine Schnittstelle kann dabei ja vieles sein. Zunächst handelt es sich nur um die Module TracRevisionLog und TracChangeset, mit welchen das Repository eingesehen werden kann, aber auch Versionsvergleiche und Diffs möglich sind.
Interessant wird das ganze allerdings erst bei der Verknüpfung. Hierfür gibt es zum einen die “manuelle” Method über TracLinks. Damit können über einen speziellen Syntax Verknüpfungen zwischen verschiedenen Trac Ressourcen hergestellt werden, also auch zwischen Tickets und Subversionänderungen.
Der andere Weg ist dabei der spannendere. Über ein “Subversion post-commit hook script” können Posts in das Trac System erfolgen, wobei dieses Script von Subversion als post-commit aufgerufen werden kann.
Das hört sich nach einer sehr spannenden Variante an. Leider endet dieser Beitrag genau da, wo es interessant wird, aber in Bezug auf die Post-Commit-Kommandos fehlt mir bisher noch einiges Detailwissen über Subversion.
Schon mehrmals haben wir über eine elegante Lösung zum Schließen der Lücke zwischen CVS und unserem Tickektsystem nachgedacht. Die Idee ist einfach: auf irgendeinem Weg muss das CVS Commit mit einem Ticket verknüpft werden können.
Grundsätzlich gibt es zwei Möglichkeiten, wenn man eine dritte Datenquelle vermeiden möchte: (1) das Speichern der jeweiligen Ticketnummer im CVS Commit oder ein Vermerk der Ressourcen und Ihrer Versionen von CVS im Ticket.
Da man als Entwickler zunächst in einer IDE wie z.B. Eclipse arbeitet, wäre eine Integration der Ticketinformationen in die Version-Kommentare vorzuziehen. Zudem hat dieser Weg den Vorteil, dass die Veränderungen am Code auch wirklich als Versionskommentare gepflegt werden, wo diese auch hingehören.
Nun bin ich erneut über Trac gestoßen, und zwar, weil es eine Subversion Schnittstelle anbietet. Eine Schnittstelle kann dabei ja vieles sein. Zunächst handelt es sich nur um die Module TracRevisionLog und TracChangeset, mit welchen das Repository eingesehen werden kann, aber auch Versionsvergleiche und Diffs möglich sind.
Interessant wird das ganze allerdings erst bei der Verknüpfung. Hierfür gibt es zum einen die “manuelle” Method über TracLinks. Damit können über einen speziellen Syntax Verknüpfungen zwischen verschiedenen Trac Ressourcen hergestellt werden, also auch zwischen Tickets und Subversionänderungen.
Der andere Weg ist dabei der spannendere. Über ein “Subversion post-commit hook script” können Posts in das Trac System erfolgen, wobei dieses Script von Subversion als post-commit aufgerufen werden kann.
Das hört sich nach einer sehr spannenden Variante an. Leider endet dieser Beitrag genau da, wo es interessant wird, aber in Bezug auf die Post-Commit-Kommandos fehlt mir bisher noch einiges Detailwissen über Subversion.