EDIT

Hallo Andreas,

weiß nicht, ob ihr bei dem Problem schon weiter seid? Soweit ich das sehe, würden aber bei allen drei Optionen die Commit-Hashes geändert und somit die bisherigen Links ungültig, oder nicht? Das würde ich in der Tat auch als Problem sehen. Folgende zwei Lösungsmöglichkeiten würden mir einfallen:

1) Wohin gehen die bisherigen Links denn genau? Falls sie an eine URL unter Deiner Kontrolle gehen, wäre es ja ggf. eine Option dort ein Redirect-Skript laufen zu lassen, das die alten Commit-Hashes zu den neuen übersetzt (also die bisherigen URLs zu den entsprechenden GitHub-URLs mit neuen Commit-Hashes per HTTP redirect umleitet). Das wäre ja einfach zu machen, sofern man eine Datenbank hat, die alt nach neu zuordnet.

Wie würde es denn genau ablaufen, wenn man die Commit History, z.B. bei Option 2 ändert? Müsstest Du dazu ein eigenes Programm schreiben, dass jeden Commit vom bisherigen Server untersucht und dann einen entsprechend veränderten Commit an GitHub schickt oder gibt es da vordefinierte Möglichkeiten? Hier wäre es dann interessant, ob bei diesem Schritt leicht eine entsprechende Zuordnungstabelle erstellt werden kann oder nicht.

2) Eine weitere denkbare Option wäre auch, dass man den bisherigen Git-Server beibehält und ein entsprechendes GitHub-Repository nur als Spiegel (z.B. mit der LSP-Option) benutzt, sofern das mit den vorhandenen großen Dateien technisch mit vertretbarem Aufwand möglich ist. Dann könnte es uns ggf. egal sein, dass die Commit-Hashes dort anders sind, da immer nur die am BGBM Server entscheidend sind und irgendwo verlinkt werden. Pull-Requests u.ä. von GitHub bekommt ja ja ggf. trotzdem leicht zum "Hauptserver" zurück und wir würden nach wie vor mit dem URLs unseres eigenen "Hauptservers" arbeiten. (Eine ähnliche Lösung haben wir für bioinfweb auch in Planung, um die Repositories der Öffentlichkeit über GitHub zugänglich zu machen, diese aber trotzdem bei uns kontrolliert liegen zu haben. Es wird aber noch dauern, bis das soweit ist.)

Bessere Optionen fallen mir im Moment leider auch nicht ein.

VG
Ben

Hallo Ben,

zu 1)
die Commit-Hash-Links befinden sich alle in Redmine, also in den Texten der Ticketbeschreibungen, den Kommentaten, Wikiseiten und zudem gibt es noch Relationen in der Datenbank zwischen Issues und den Tabellen in denen Redmine Repositories indiziert.
Man könnte also ein Radmine-addon schreiben, dass die alten commit hashes auf die neuen mappt.

Beim recherchieren zu diesem Thema bin ich auf diesen Forumsbeitrag zum BFG Repocleaner gestoßen: http://howtoprogram.eu/question/n-a,48972 https://rtyley.github.io/bfg-repo-cleaner/

Dieser macht genau anscheinen das was wir brauchen, entfernt zu große Objekte , schreibt also die History um, speichert die alten Commit hashes als Footer der Commit-Message: Former-commit-id:

Wir bräuchten also "nur" ein redmine plugin das diesen Footer auswertet. Vielleicht hat das schon mal jemand geschrieben?

zu 2)
die LSP-Option kenne ich noch nicht, werde ich mir aber anschauen.

Hallo Andreas,

1) das Redmine-Plugin wäre eine Möglichkeit, die ja im Prinzip das gleiche wie ein URL-Redirector macht. Welche von beiden nun leichter zu implementieren ist kann (mangels Detailkenntnissen von Redmine) nicht sagen. Ein URL-Redirector wäre sicherlich nicht sehr aufwendig und hätte ggf. den Vorteil, dass alle alten URLs prinzipiell gültig bleiben (und damit auch in Redmine nicht zwangsläufig geändert werden müssen) und somit auch alle Links, die evtl irgendwo anders noch existieren (in Wikis, persönlichen Notizen, Daten von Dritten oder was auch immer) auch weiterhin funktionieren würden. Ab jetzt könnte man dann ja in Redmine trotzdem die neue URLs verwenden. Will gar nicht zwangsläufig von einem Redmine Plugin statt einem URL-Redirector abraten, wollte nur noch mal auf diese Vorteile eines Redirectors hinweisen.

2) LSP kenne ich im Detail auch nicht. Grundsätzlich ist es wohl einfach eine Möglichkeit die großen Dateien woanders zu speichern. Am schönsten wäre es natürlich (egal ob LSP oder ein anderer Speicher verwendet wird), wenn das neue Repository wenigstens Links zu den entfernten Dateien statt diesen selbst enthalten würde, z.B. einfach in Form einer Textdatei, die nur einen Hinweistext auf die Größenbeschränkung und eine URL unter der die bisherige Datei zu finden ist enthält. Weiß nicht, ob Repocleaner oder auch das LSP-System von GitHub dazu bereits automatisierte Möglichkeiten bieten. Falls ja, wäre es sicher schön die zu nutzen. Falls dazu aber auch wieder eigene Plugins benötigt würden, wäre es sicher abhängig von der Frage, wie wichtig es ist, alte Zustände des Repositories vollständig rekonstruieren zu können.

VG
Ben

Hallo Ben,.

1)
die Commit links in Redmine sind zunächst reine markdown syntax, z.B: commit:cdm-vaadin|05ce260 Nur wenn redmine den Commit 05ce260 im Git repository cdm-vaadin kennt, wird beim Interpretieren des Markdown ein HTML Link daraus. Ein URL-Redirector wie du ihn vorgeschlagen hast würde voraussetzen, dass die HTML Links immer generiert werden. Dies würde wiederum bedeuten, dass man ein neues Addon entwickeln oder bestehende Funktionalität in Redmine erweitern müsste.

Viele Grüße
Andreas

Hallo,

kann man eigentlich eine Mapping Tabelle erstellen (altes Commit-neues Commit)?
Da ließe sich doch relativ leicht ein skript schreiben, welches die alten Commits anpasst in Redmine.

Fände ich besser, als eine Redirect-Lösung die dann dauerhaft supported werden muss.

Viele Grüße,
Andreas M.

Meinst du mit anpassen, dass die Einträge der alten Commits durch neue ersetzt werden, also auf Datenbank Ebene?
Das ist auf jeden Fall auch eine Lösung. Folgende Bereiche des Redmine Datenmodells sind betroffen:

• Texten der Ticketbeschreibungen
• den Texten Issue-Kommentare,
• Wikiseiten
• Relationen zwischen Issues und den Tabellen in denen Redmine Repositories indiziert

Viele Grüße
Andreas

Meinst du mit anpassen, dass die Einträge der alten Commits durch neue ersetzt werden, also auf Datenbank Ebene?

Ja, das war die Idee.

Wie gesagt, das ist im Prinzip eine gute Idee.
Wie aufwendig die Umsetzung dieser Lösung im Vergleich zu einem Addon ist müssen wir mal sehen.
Wir könnten dafür entweder eine Stored-procedure schreiben oder vielleicht ist ein rake script sogar einfacher weil Übersichltlicher in der Umsetzung, wegen der Debug Möglichkeiten und dem Logging.

Andreas

Hi,

ja wie man das skripted ist letztlich egal, würde ich sehen, welche Sprache für das Problem am leichtesten ist. Ist ja nur ne einmalige Sache, kann also quick, dirty und unhandlich sein, so lang es funktionert.
Aus Java heraus ließe sich das sicherlich auch sehr schnell implementieren (evtl. schneller als mit den anderen Sprachen, da wir uns mit Java wahrscheinlich am besten auskennen).

Das Hauptproblem bei dem Skript sehe ich eigentlich daran, dass die commits ja in unterschiedlicher Länge vorhanden sein können, also von ca. 6 Zeichen bis alle Zeichen, das müsste man also mitberücksichtigten. Ansonsten ist vermutlich straight forward, wenn man weiß in welchen Tabellenfeldern die Texte vorkommen können. Aber hast du ja schon eine Liste erstellt.
Haben wir da schon ein Ticket für?

Und wenn wir irgendeine Stelle vergessen, ist es auch nicht so kritisch. So lange man die Mappingtabelle irgendwo speichert, kann man das ja noch nachholen oder, wenn dann wirklich einmaliger Nachschlagebedarf ist, dort direkt nachschauen.

Viele Grüße,
Andreas M.

Eine weitere Möglichkeit ist der Umzug auf Gitlab.com.

"To celebrate today's good news we've permanently raised our storage limit per repository on GitLab.com from 5GB to 10GB. As before, public and private repositories on GitLab.com are unlimited, don't have a transfer limit and they include unlimited collaborators." (https://about.gitlab.com/2015/04/08/gitlab-dot-com-storage-limit-raised-to-10gb-per-repo/)

Andreas Kohlbecker wrote:

Eine weitere Möglichkeit ist der Umzug auf Gitlab.com.

"To celebrate today's good news we've permanently raised our storage limit per repository on GitLab.com from 5GB to 10GB. As before, public and private repositories on GitLab.com are unlimited, don't have a transfer limit and they include unlimited collaborators." (https://about.gitlab.com/2015/04/08/gitlab-dot-com-storage-limit-raised-to-10gb-per-repo/)

transfer limit VS file size limit. Oben in der Beschreibung steht, dass es an der Dateigröße liegt, oder?