Bei git hat man ein distributed Versionscontrolsystem. D.h. jeder kann seine eigene git Instanz lokal auf seinem Rechner haben, damit arbeiten und später alles zu der git Instanz hochladen, die als zentrale Git Instanz ausgewählt wurde. Was ich mich nun frage ist, ob es so etwas auch für Bug-, Issue- und Projektmanagementsysteme gibt? Also eine Projektmanagementsystem das verteilt arbeiten kann? Bei dem ich also bspw. eine Hauptinstanz habe. Davon holen sich alle Teammitglieder die derzeitige Listen und Inhalte zu aktuellen und geschlossenen Bugs, Issues und Todos runter. Lokal arbeiten sie dann mit einer eigenen Instanz der Projektmanagementsoftware weiter. In dieser können sie Bugs, Issues und Todos abarbeiten oder neue hinzufügen. Und irgendwann laden sie ihre Änderungen auf die Hauptinstanz wieder hoch, also mergen alles. Der ein oder andere wird sich jetzt fragen wozu man das brauchen könnte. Immerhin kann man eine Projektmanagementsoftware auch einfach auf einen Server ins Internet stellen und so alles zentral verwalten. Und bei einer verteilten Projektmanagementsoftware kann man ja nicht verhindern, dass zwei Leute am gleichen Bug arbeiten, also würde doppelte Arbeit gemacht werden, was kontraproduktiv ist. Nun, das mag alles sein, in meinem speziellen Fall will ich aber meine Projektmanagementsoftware an verschiedenen Orten ohne Internetverbindung haben. Nur der Rechner wird hin und hergeschleppt. D.h. auf dem könnte man die Projektmanagementsoftware auch installieren, aber dem Rechner fehlen die Eigenschaften eines NAS auf dem die zentrale Instanz des Projektmanagementsystem laufen soll. D.h. auf dem NAS soll die zentrale Instanz der Projektmanagementsoftware laufen und ab und zu müssen die Daten im Projektmanagementsystem der zentralen Instanz auf dem NAS natürlich aktualisiert werden, wenn ich mit einer lokalen Kopie auf dem Rechner gearbeitet habe. So etwas wäre bspw. auch im mobilen Betrieb mit dem Notebook sehr praktisch. Dann könnte man unterwegs an seinen Bugs arbeiten, die Bugs in der Projektmanagementsoftware als "done" markieren und dann, wenn man wieder Zuhause ist, alles ins zentrale Projektmanagementsystem mergen. Ohne so eine Funktion hat man nämlich unterwegs keinen Zugriff auf seine Bugs oder Issues, wenn das Projektmanagementsystem Zuhause nur im lokalen Netzwerk hängt und nicht per Internet erreichbar ist oder man unterwegs einfach kein Internet hat. Dafür wäre eine Projektmanagementsoftware die wie git verteilt arbeiten kann optimal. Gibt es so etwas? Idealerweise als Open Source Software?
Nano schrieb: > Bei git hat man ein distributed Versionscontrolsystem. D.h. jeder kann > seine eigene git Instanz lokal auf seinem Rechner haben, damit arbeiten > und später alles zu der git Instanz hochladen, die als zentrale Git > Instanz ausgewählt wurde. > > Was ich mich nun frage ist, ob es so etwas auch für Bug-, Issue- und > Projektmanagementsysteme gibt? > Also eine Projektmanagementsystem das verteilt arbeiten kann? Fände ich auch ganz praktisch, kenne ich aber leider nicht. Generell ist der Aufwand für solch ein verteiltes System aber auch viel höher als bei den einfachen Dateien, die mit git verwaltet werden. Bei git werden keine Verknüpfungen zwischen den Dateien berücksichtigt, daher kann man jede Datei einzeln versionieren. Die meisten Projektmanagementsysteme basieren aber auf einer SQL-Datenbank. Es gibt zwar DBMS, die eine Multi-Master-Replikation anbieten, aber damit ist nicht das Problem der aggregierten Daten gelöst. Wenn also zu einem Bug-Eintrag mehrere Datensätze mit den gearbeiteten Stunden erfasst werden, wird die Summe häufig in dem Bug-Eintrag selbst aufsummiert, damit die Performance der Anzeige steigt. Bei einem zentralen System ist das auch kein Problem, läuft ja alles in einer Transaktion ab. Bei einem verteilten System müsste man aber eine Fehlerbehandlung einbauen für den Fall, dass die Summe im Bug nicht mehr mit der Summe der einzelnen Stunden-Datensätze übereinstimmt. Dieser Fall tritt auf, wenn zwei Benutzer fast zeitgleich ihre Daten hochladen und am gleichen Bug gearbeitet haben. Das ist noch ein sehr einfaches Beispiel, das man mit einem Trigger lösen könnte. Es gibt viele andere Situationen, die ein manuelles Eingreifen erfordern. Machbar ist das also, aber ziemlich aufwändig. Vielleicht hat es schon einmal jemand umgesetzt, habe ich aber noch nicht gesehen.
Gibt es. Eher zu viel als zu wenige, und es wird schwer eins auszusuchen das alles kann was du willst und dann auch noch gepflegt wird. https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Bug.2Fissue_trackers.2C_etc.
Beim Link hinten noch den Punkt mit dazunehmen, sonst kommt man nicht zum richtigen Abschnitt.
Sebastian schrieb: > Gibt es. Eher zu viel als zu wenige, und es wird schwer eins > auszusuchen > das alles kann was du willst und dann auch noch gepflegt wird. > > https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Bug.2Fissue_trackers.2C_etc. Danke für den Link. Ich bin jetzt mal alle durchgegangen, aber da scheint wohl nichts wirklich brauchbares dabei zu sein, was mit Trac oder Redmine mithalten kann. Die meisten Projekte sind verweist, d.h. die Links laufen in einen 404 Error oder ähnliche Fehlermeldungen. Von dem was übrig bleibt ist vieles nur ein Kommandozeilentool, also kein Bugtracker mit Webinterface, bei einigen war der letzte Code Commit vor 5 Jahren. Das ist also nichts, womit man seine eigenen Projekte pflegen will. Einige weitere Projekte sind Plugins für bekannte Bugtrackingsysteme bzw. Commandline Tools für solche, die sicherstellen, dass der git commit auch eine Bug ID enthält. Manches Tool hat nicht die verteilte Fähigkeit, die ich suche. Und eines ist sogar dabei, bei dem der Quellcode nicht mehr da ist, weil der Hosting Dienst gitorius auf dem der Quellcode gehostet wurde, eingestellt wurde. Im großen und ganzen war leider nichts dabei was ich suche oder zumindest meinen Erwartungen entspricht. Schade, aber trotzdem Danke für den Tipp.
Nano schrieb: > Bei dem ich also bspw. eine Hauptinstanz habe. > Davon holen sich alle Teammitglieder die derzeitige Listen und Inhalte > zu aktuellen und geschlossenen Bugs, Issues und Todos runter. > > Lokal arbeiten sie dann mit einer eigenen Instanz der > Projektmanagementsoftware weiter. > In dieser können sie Bugs, Issues und Todos abarbeiten oder neue > hinzufügen. > Und irgendwann laden sie ihre Änderungen auf die Hauptinstanz wieder > hoch, also mergen alles. evtl dokuwiki (mit lokalem server), gitbacked-plugin und evtl. markdowku? da dokuwiki nur mit text-dateien arbeitet kann man das auch (recht) problemlos lokal ohne web-frontend davor bearbeiten/lesen/erstellen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.