Es ging um eine leichtgewichtige Alternative. Dazu kann Redmine wohl nicht gezählt werden. Außerdem kann man sich, im Gegensatz zu Redmine, in Trac nicht im Dschungel der Kategorien und Wikis verschiedenster Projekte verlieren. Die Zuordnungen sind klar und einfach. Die Tatsache, dass quasi nur ein Hauptprojekt unterstützt wird, sehe ich eher als einen Vorteil von Trac.
Genau das ist auch mein Problem mit Redmine, ich muss mich AFAIK durch dass Webfrontend "klicken". Für Trac habe ich Skripte denen ich den Projektnamen und die LDAP-Gruppe übergebe, daraus wird dann eine Trac Instanz inklusive Apache Konfiguration und je nachdem ob das Trac+SVN oder das Trac+Git Script ausgeführt wurde ein passendes Repository inklusive Apache Konfiguration angelegt.
Für die nächsten Trac Versionen ist aber auch hier die Möglichkeit einer Multiprojekt-Instanz geplant, soweit ich weiß ist dass aber kein muss und ich kann weiterhin für jedes Projekt eine eigene Instanz erstellen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 12. Jul 2012 um 19:06.
Richtig, Redmine oder ChiliProject sind Trac in jeder Hinsicht überlegen. Ich habe kein Verständnis dafür, wie man heutzutage noch Trac einsetzten kann.
Ok, ich habe den Artikel gerade gelesen und revidiere meine Aussage. Für solche Minimalanforderungen ist Trac sicher gut geeignet.
Alle anderen sollten sich mal Redmine oder ChiliProject anschauen. Ich nutze das mittlerweile für alles. Egal ob Softwareprojekt, oder Urlaubsplanung. Kann ich jedem nur Empfehlen.
Von Jochen Schnelle am Fr, 13. Juli 2012 um 07:49 #
So isses. Für kleine Projekt mit übersichtlicher und / oder geschlossener Benutzergruppe ist Trac einfacher und schneller. Für große Sachen mag es bessere und umfassendere Alternativen geben.
> Redmine oder ChiliProject sind Trac in jeder Hinsicht überlegen
Die Aussage kann man leicht widerlegen. Ein Aspekt, der dich vielleicht zum Nachdenken anregt: Trac ist in Python geschrieben. Das könnte ja schon mal für manche ein Vorteil sein?
Stimmt, Python ist mir auch lieber als Ruby. Allerdings baut Trac nicht auf einem Web-Framwork wie Django auf. Ich glaube nicht, dass das eine gute Idee ist. Ok, mit Webentwicklung kenne ich mich auch nicht aus, ist halt nur so ein Gefühl.
Redmine /ChileProject basieren auf Ruby on Rails. Das ist ein sehr beliebtes Web-Framework. Ohne Rails würde Ruby heute wahrscheinlich kaum noch eine Rolle spielen.
Von Jochen Schnelle am Fr, 13. Juli 2012 um 21:24 #
Trac nutzt Genshi als Template-Engine (ebenfalls von Edgewall). Genshi ist zusammen mit Jinja2 und Mako eine der drei "großen" Python Template Engines. Ansonsten ist es IMHO nicht unbedingt ein Qualitätsmerkmal, ob eine web-basiertes Programm auf ein großes Webframework setzt oder nicht. Zumal Trac ja recht einfach ist und auch ohne ORM oder Formular-Bibliothek auskommt. Außerdem nutzt Trac AFAIK recht intensiv jQuery.
Naja, ich bin eigentlich auch eher Python zugeneigt, allerdings muss ich in diesem Fall sagen, dass ich mir lieber den sauberen Ruby Code von Redmine als den katastrophalen Python Code von Trac antun würde.
Trac???
Das benutzt noch jemand für neue Projekte??
Was wäre deiner Meinung nach eine ähnlich leichtgewichtige Alternative?
Redmine?
Und was ist daran jetzt wirklich besser? Macht schon einens chicken Eintruck, würde aber gerne die Vorteile wissen.
Es ging um eine leichtgewichtige Alternative. Dazu kann Redmine wohl nicht gezählt werden.
Außerdem kann man sich, im Gegensatz zu Redmine, in Trac nicht im Dschungel der Kategorien und Wikis verschiedenster Projekte verlieren.
Die Zuordnungen sind klar und einfach.
Die Tatsache, dass quasi nur ein Hauptprojekt unterstützt wird, sehe ich eher als einen Vorteil von Trac.
Gruß vom andih
Genau das ist auch mein Problem mit Redmine, ich muss mich AFAIK durch dass Webfrontend "klicken".
Für Trac habe ich Skripte denen ich den Projektnamen und die LDAP-Gruppe übergebe, daraus wird dann eine Trac Instanz inklusive Apache Konfiguration und je nachdem ob das Trac+SVN oder das Trac+Git Script ausgeführt wurde ein passendes Repository inklusive Apache Konfiguration angelegt.
Für die nächsten Trac Versionen ist aber auch hier die Möglichkeit einer Multiprojekt-Instanz geplant, soweit ich weiß ist dass aber kein muss und ich kann weiterhin für jedes Projekt eine eigene Instanz erstellen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 12. Jul 2012 um 19:06.AFAIK = as far as I know
Na ja, ich kenne schon ein paar Projekte und Leute ("Hobby-Programmieren", nicht OpenSource mit Entreprise-Level Ambitionen), die alle Trac nutzen.
Richtig, Redmine oder ChiliProject sind Trac in jeder Hinsicht überlegen.
Ich habe kein Verständnis dafür, wie man heutzutage noch Trac einsetzten kann.
Ok, ich habe den Artikel gerade gelesen und revidiere meine Aussage.
Für solche Minimalanforderungen ist Trac sicher gut geeignet.
Alle anderen sollten sich mal Redmine oder ChiliProject anschauen.
Ich nutze das mittlerweile für alles. Egal ob Softwareprojekt, oder Urlaubsplanung. Kann ich jedem nur Empfehlen.
So isses. Für kleine Projekt mit übersichtlicher und / oder geschlossener Benutzergruppe ist Trac einfacher und schneller. Für große Sachen mag es bessere und umfassendere Alternativen geben.
> Redmine oder ChiliProject sind Trac in jeder Hinsicht überlegen
Die Aussage kann man leicht widerlegen. Ein Aspekt, der dich vielleicht zum Nachdenken anregt: Trac ist in Python geschrieben. Das könnte ja schon mal für manche ein Vorteil sein?
Stimmt, Python ist mir auch lieber als Ruby.
Allerdings baut Trac nicht auf einem Web-Framwork wie Django auf.
Ich glaube nicht, dass das eine gute Idee ist.
Ok, mit Webentwicklung kenne ich mich auch nicht aus, ist halt nur so ein Gefühl.
Redmine /ChileProject basieren auf Ruby on Rails.
Das ist ein sehr beliebtes Web-Framework. Ohne Rails würde Ruby heute wahrscheinlich kaum noch eine Rolle spielen.
Trac nutzt Genshi als Template-Engine (ebenfalls von Edgewall). Genshi ist zusammen mit Jinja2 und Mako eine der drei "großen" Python Template Engines.
Ansonsten ist es IMHO nicht unbedingt ein Qualitätsmerkmal, ob eine web-basiertes Programm auf ein großes Webframework setzt oder nicht.
Zumal Trac ja recht einfach ist und auch ohne ORM oder Formular-Bibliothek auskommt.
Außerdem nutzt Trac AFAIK recht intensiv jQuery.
Naja, ich bin eigentlich auch eher Python zugeneigt, allerdings muss ich in diesem Fall sagen, dass ich mir lieber den sauberen Ruby Code von Redmine als den katastrophalen Python Code von Trac antun würde.