Trac gegen Redmine

Würde ich zugunsten Trac. Ich habe Trac eine lange Zeit über 7 Jahren jetzt. Ich habe auch arbeitete 3 Jahre mit Redmine. Neuesten Versionen, die ich in der Produktion eingesetzt wurden: Trac 1.0.1 und Redmine 2.2.3. Aber Redmine hat einige gravierende Nachteile gegenüber Trac:

1. Installation ist nicht einfach:

   1. Können Sie nicht verwenden, Debian - /Ubuntu-Paket-system für die Produktion verwenden

      • Als Konfiguration ist nicht getrennt vom Anwendungscode, wenn Sie Paket-updates, Sie werden Ihre änderungen überschrieben werden.
      • Debian hatte 5 Sicherheitslücken, die Anfang 2013 (Januar), wo einige noch lose in den unstable-und testing. Natürlich Korrekturen in Debian-stable fertig ist, wird die Paket-Versionen sind also nicht mehr im Stall, dass neuere Versionen von Redmine wird nicht funktionieren.
      • Redmine Abhängigkeiten behoben werden, sodass neue library-Versionen funktionieren möglicherweise nicht. Dies ist der Grund, müssen Sie Ihre apt-get oder aptitude nicht zu aktualisieren, bestimmte Abhängigkeiten.

   2. Berate ich Sie zu installieren, die über gem und bundler. Jedoch war dies so einfach wie beschrieben auf der homepage. Aber was ich hasse am meisten über diese software-Paket-management-Systeme neben der systems Paket-management ist, dass du die Betreuung für updates und alle anderen Sachen getrennt. Einige Leute empfehlen die RVMdie die virtuelle ruby-Umgebungen, wo Sie mehrere Rails-Versionen nebeneinander installiert, das ist nicht möglich, mit apt-get. Ich fühle mich nicht gut, aber zumindest funktioniert es.

2. Verwaltung ist nicht einfach, angesichts der Erstellung einer backup: In Trac das ist ein Einzeiler, in Redmine, müssen Sie zum sichern: - Konfiguration, Dateien und Datenbank-Inhalte alle separat. Darüber hinaus ist es oft festgestellt, dass Redmine unterstützt mehrere Projekte, so dass es einfacher, um das setup ein neues Projekt und die Konfiguration wird nicht dupliziert. Siehe unten, dort ist ein extra Absatz auf mehrere Projekt-Unterstützung. Last but not least, wenn ich die Verwaltung eines Trac-Projekts, die ich Liebe, zu Bearbeiten PLAIN-TEXT-Konfigurationsdateien. Im Trac gibt es nur eine solche Datei, die Sie brauchen, zu betrachten: trac.ini.

3. Konfiguration ist gebrochen: Z erstellen Sie benutzerdefinierte Routen in Redmine, die zeigen, dass die start-wiki-Seite und nicht die Projekt-übersicht als erste Seite. Sie wird empfohlen, zu Bearbeiten Redmine Quellen! Das ist sehr gefährlich, da nächsten update überschrieben werden, die Ihre Konfiguration. Also solche Art der Konfiguration wurde nicht wirklich gedacht. Aber ein gutes Werkzeug zu trennen, um die Konfiguration aus dem Quellcode der Anwendung.

4. Wiki-Funktionen fehlen: Einige wichtige wiki-Funktionen fehlen aufgrund eines unfixierten Fehler im Zusammenhang mit einer XSS-Schwachstelle. (z.B. siehe Textil-wiki-markup). So werden Sie am Ende nicht in der Lage, Kommentare in wiki-Seiten, das Rendern von Bildern in der kundenspezifischen Größe,...

5. Fehlende Spam-Schutz: ja, es ist eine veraltete reCaptach plugin, aber es funktioniert nicht mehr. Vor allem die Gabel auch um den Schutz der Problem-Seiten. Im Vergleich zu Trac hat ein SpamFilter-plugin, das hat fantastische Eigenschaften das ist ein no-go. Niemand will spam löschen manuell.

Viele kritische Punkte wurden im Laufe der Zeit gemacht, dass die Leute sagen, Redmine ist besser. Ich Zweifel diese:

1. Multiproject-Unterstützung: natürlich Trac bietet mehrere Projekte, von denen jeder seine eigene Konfiguration!, und das ist sehr hilfreich: Erwägen Sie, ein Projekt closed-source und eine offene Quelle. Für die geschlossene Quelle, die Sie wahrscheinlich verstecken Sie das Repository, aber nicht für die open-source-Projekt. dies ist nicht möglich, mit Redmine. Darüber hinaus mit Trac kannst du ein Backup der Projekte separat und natürlich Sie können trennen Sie incase eines Ihrer 50 Projekte populär geworden, so wird es brauchen, einen eigenen server! Redmine kann dies nicht tun. Vor kurzem, ein neues plugin kam die Unterstützung mehrerer Benutzer-Projekte in einer Trac-Instanz, Blick auf http://trac.edgewall.org/wiki/PluginList#MultipleProjects

   Außer, dass, es ist ein Projekt mit Trac zu bauen, die diese Funktion: Bluthund

2. Version Control System: ich denke, die Installation eines plugins ist nicht schwer, und für fast alle VCS-es gibt ein plugin für Trac: Git, Perforce, Mercurial, Darcs, Monotone, Subversion, Bazaar. Desweiteren würde ich zugunsten einer kleinen core-framework mit plugins über einen großen Rahmen mit integrierter Unterstützung für Git, Mercurial, usw... Solche Architektur ist nicht modular aufgebaut. So setzen VCS-Unterstützung für plugins ist der Weg, es zu tun. Nicht zu integrieren, alles in den Rahmen.

3. Plugins: ich würde behaupten, Trac und Trac-Hacks haben viel mehr plugins als Redmine, also die integration von Doxygen, Jenkins, Latex, BibTex, etc.. ist kein problem!

4. Timing und Einschätzung: Es gibt plugins in Trac zu!
   Alles in allem verstehe ich nicht, die letzten Trac-bashing, Es ist auch geschrieben in einem modernen interpreter-Sprache (python), es hat fast die gleiche Funktionalität.

Redmine - installation ist nicht leicht, aber der Trac-installation wurde auch komplexere diesen Tagen, so dass manuelle Erstellung der Datenbank, etc. kann nicht zählen, wie ein Nachteil mehr.

Last but not least, beide Projekte mit einem plugin-system. Das problem der Benutzer diese plugins oft hat ist, können Sie verwaiste und nicht die Unterstützung der aktuellen Rahmenbedingungen. Es passiert mir mehr als ein Dutzend mal für Redmine, aber manchmal auch für Trac. Aber mein ganz subjektiver Eindruck ist, dass entscheidend plugins waren nie betroffen von dieser Art von problem und mit Trac passiert, dass ein bisschen weniger.

Letzte, aber nicht zuletzt auch am wenigsten, ich werde versuchen, aus Phabricatorwie es bietet vordefinierte Workflows für code-review.

InformationsquelleAutor der Antwort math

Ich arbeite sehr viel mit redmine, und ich Liebe es!

1. svn und/oder dcvs (Git) unterstützen

   haben es beide. wenn Sie fügen Sie die Ticketnummer ein, um die commit-Nachricht, die commit-erscheint sehr elegant in das ticket, dies ist einer meiner Lieblings-features als Entwickler 🙂

2. Dokumenten-management -

   habe es auch, aber nur sehr minimal. Sie können Dateien hochladen, um tickets und Projekte (getrennt) aber man kann nicht nach Ihnen suchen (dh)

3. ticketing -, bug-tracking, wiki

   ja, ja und ja...:) ich mag die syntax zum schreiben von tickets oder anderen text-Inhalt, Art vergleichbar mit der syntax an stackoverflow.com.

4. mehrere Projekt-Unterstützung

   Ursache, die Sie erstellen können Projekte, Teilprojekte, sub-sub-Projekte.... mit unterschiedlichen Zugriffs-Rechte, wenn nötig. Sie können dies auch tun, Kaskadierung mit tickets.

5. installation und plugins

   Habe ich nie installiert, eine redmine-Instanz, und ich habe keine Erfahrung mit ruby. Ich bin nur ein redmine-Benutzer, aber ich weiß, dass es möglich ist, eigene Erweiterungen (meine Firma geschrieben hat, eine für die eigenen Zwecke zu erweitern, die tracking-Zeit)

Fazit: ich immer verwenden Redmine, wenn ich ein ticket-system!

Update: Manchmal bin ich auch mit dem Problem der integration der code-Hoster wie bitbucket oder github. Redmine ist die größte Lösung, die ich bisher verwendet habe. Trello ist auch eine alternative, die ich mag zu verwenden, um Bearbeiten von Kunden-Aufgaben (man kann teams erstellen), wenn nicht viele Leute sind beteiligt, und das Projekt ist nicht so groß.

InformationsquelleAutor der Antwort Armin

Wir nutzen Redmine seit einiger Zeit. Es kann schwierig gewesen sein, zu installieren, in der Vergangenheit (ich denke nicht so), aber Ubuntu enthält jetzt ist es so dass die Installation ist ein einfacher one-liner "apt-get install roten Grube". Dann schalten Sie einfach den PKW-Modul "a2enmod passenger" und aktivieren Sie anschließend die redmine Seite.

InformationsquelleAutor der Antwort Wayne