Hallo,

ihr solltet euch mal überlegen, das Projekt von eurem eigenen SVN nach Github zu migrieren. Es existieren entsprechende Tools zur Migration von SVN nach GIT.
Vorteil wäre, dass ihr endlich auch mehr Mithilfe bei der Entwicklung durch die Community in Form von Pull Requests zu erwarten hättet.
Außerdem könnte man die Änderungen endlich auch komfortabel über eine Weboberfläche mitverfolgen.
Eure Projekte sind in der aktuellen Form absolut Einstiegs-unfreundlich für neue Entwickler, und wer wirklich von der Community profitieren möchte als Open Source Projekt, der kommt um Github nicht herum.

Grüße von einem Entwickler

[Jiaz]

Wir haben damals mit SVN angefangen und haben seit dem keinen Grund gesehen/Bedarf gehabt nach GIT zu wechseln.
SVN ist fester Bestandteil in vielen Bereichen:
1.) Eclipse hat eine klasse SVN Integration
2.) Wir nutzen SVN ebenfalls innerhalb des Übersetzungs-Moduls im JDownloader, so dass alle Übersetzer direkt auf dem Repo Arbeiten, inklusive Merge/Konflikt-Lösung
3.) Der komplette Build-Process hängt am SVN
4.) Redmine hängt am SVN

Während 1 primär vom Entwickler abhängt und oftmals Geschmackssache ist, würde eine Änderung von 2,3 und 4 viel Aufwand mit sich bringen.

Zusätzlich bietet GIT keine Permissions an. Innerhalb des SVN liegen eben auch Hidden/Group XY Only Teile und nicht jeder Entwickler hat alles Zugriff. Übersetzer zb können nur an den TextFiles Änderungen vornehmen. Soweit ich weiß geht das mit GIT nicht?! Ich lasse mich aber gerne des besseren belehren!

Auch sehe ich in einem Pull Request keinen Vorteil gegenüber einen Patch-File. In beiden Fällen muss der Entwickler so oder so zuvor ein Contributor Agreement unterzeichnen. Sprich einfach pullen ist eh nicht.

Wenn ein Entwickler sein Interesse am Projekt alleins an der Frage SVN oder GIT abhängig macht, dann ist das wieder mehr eine Frage des VCS als die Frage ob man am Projekt wirklich mitarbeiten möchte. Denn im Vordergrund sollte das Projekt stehe und nicht sein VCS.

Grüße von Jiaz

Hallo Jiaz,

vielen Dank für deine Erläuterungen. Ich kann deine Argumente grundsätzlich nachvollziehen. Was die Permissions betrifft, sollte so etwas im Rahmen von Github Organizations regulierbar sein **External links are only visible to Support Staff****External links are only visible to Support Staff** (eine Organization kann in der Regel auch hidden Repos haben, für non-public Codeparts).
Auf Github ist es üblich, dass man beliebte Repos forkt und dann Pull Requests erstellt, ohne zuvor etwas unterzeichnen zu müssen. Der Entwickler kann den Request ja begründet oder unbegründet ablehnen.
Mein Argument ist, dass auf Github eben die Einstiegshürde, zu einem Projekt etwas beizutragen, viel niedriger ist, als irgendwo anders.
"Wenn ein Entwickler sein Interesse am Projekt alleins an der Frage SVN oder GIT abhängig macht" - Ihr solltet es nicht wie ein Bewerbungsgespräch sehen: Nicht Entwickler XY muss froh sein bei eurem tollen Projekt mitwirken zu dürfen, sondern Entwickler XY muss es erst mal schmackhaft und so einfach wie möglich gemacht werden, bei eurem Projekt mitzuhelfen und seine Arbeitskraft kostenlos einzubringen. Whatsapp ist auch nur so erfolgreich, weil der Einstieg und das Setup so einfach sind. Was Otto-Normal-Entwickler schon gar nicht will, ist dafür, dass er kostenlos wo mithilft, auch noch vorab etwas unterzeichnen zu müssen. Da empfiehlt es sich, eher so vorzugehen, dass nach X akzeptierten Pull Requests von User XY dieser eventuell mal Schreibzugriff auf das Repo bekommt, und dann kann er ja immer noch etwas unterschreiben.

Aber ja, ich wollte euch das nur als Feedback geben, ich persönlich kann auch mit SVN umgehen und habe eure Repos unter Netbeans in Verwendung.

Wieso Open-Source Projekte heutzutage noch kein Github benutzen, ist mir allerdings auch ein Rätsel. Gerade der jD, was ich klar als "Community-Projekt" deklarieren würde, hätte dadurch doch nur Vorteile. Ich bin zwar auch "nur" Webentwickler, bezüglich Transparenz und Usability ist Github allerdings kaum zu übertreffen.

Würde einen Wechsel ebenfalls begrüßen. Zudem man dann gleich einen Bugtracker integriert hätte, was ebenfalls wesentlich komfortabler als die momentane Lösung wäre.

[Jiaz]

Natürlich kann ich mehrere Repos auf GitHub erstellen. Aber ein einzelnes Repo in dem ich bestimmten Nutzer/Nutzergruppen individuelle Rechte vergeben kann, falls gewünscht sogar Dateibasierend, ist mit GIT eben nicht machbar.

Ein Umbau der ganzen Repo-Struktur wäre mit viel Aufwand verbunden (Anbindung an JD, Nutzerverwaltung, Anbindung an Build/Update Prozess, Anbindung an Redmine). Und ein richtiger Vorteil von GIT gegenüber SVN, der diesen Aufwand rechtfertigen würde, erschließt sich, meiner Meinung nach, eben nicht.

Natürlich mag Github sehr *bequem* sein, weil man einfach drauf los "coden" kann und alles in einem hat (VCS,Bugtracker, Webinterface...) Aber einmal das SVN Repo via Eclipse/SubClipse/SubVersion ausgecheckt, ist es selbst für den Java-Neuling/Anfänger leicht zu bedienen.

Ein Contributor Agreement ist in jedem Fall vonnöten. Egal ob bei der Zusendung eines Patches, dem Akzeptieren eines Pull-Requests oder dem Erstellen eines Entwickler-Accounts.

Ich empfinde somit die Hürde (Auschecken eines SVN Repos vs GitHub) für neue Entwickler oder Interessierte als sehr gering. Die meiste Zeit geht eh für die Einrichtung aller Repos in der IDE drauf.

Auch nutzen wir Redmine, weil wir eben "Herr" über den Bugtracker sein wollen. Wir haben zb. eine Anbindung an das Forum hier, damit wir Tickets direkt verlinken können. Ebenfalls wird die API/Datenbank von Redmine in weiteren Teilbereichen stark verwendet. Auch können wir jederzeit Modifikationen vornehmen wie es uns beliebt.
Auch ist das Ticket/Forum-System bei uns für normale Anwender bestimmt, während Redmine ausschließlich JD-Entwicklern vorenthalten ist. So ist eine strikte Trennung der beiden Bereiche gewährleistet.

Ein großer Nachteil der mir einfällt der gegen GIT spricht wäre das man immer eine komplette Kopie hat? Auch hier korrigiert mich bitte? Aber während ich bei SVN nur die derzeitige Revision/Head lokal vorrätig habe, liegt bei GIT die komplette History auf der Platte? Und das wäre zb im Fall von JD schon einige GB an Daten, da wir viele größe Binärdateien haben.
Aber auch mein GIT-Wissen ist nur Mangelhaft, daher lasse ich mich gerne eines Besseren belehren.

Und "hidden/closed" Repos auf GitHub kosten auch Geld.

Was genau stört denn an Redmine/Forum? @Conte