• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Der nächste Umzug - Google Code schließt

MiK

Geoguru
Hallo,

ich habe heute die Nachricht bekommen, dass Google Code demnächst dicht macht (genaue Nachricht unten). Wir müssen uns also wieder ein neues Zuhause suchen.

Ich wäre dafür bei SVN als Versionsverwaltung zu bleiben. Sie ist relativ einfach und ich kenne mich sehr gut damit aus. Damit können wir die History behalten und alles 1:1 übernehmen. Die nötigen Befehle für einen Umzug habe ich noch hier vom Berlios-Umzug.

Die Frage ist jetzt: Wo wollen wir hinziehen? Ich habe mich noch nicht genauer umgesehen und bin für Vorschläge offen.

Nachricht von Google:
Hello,

Earlier today, Google announced we will be turning down Google Code Project Hosting. The service started in 2006 with the goal of providing a scalable and reliable way of hosting open source projects. Since that time, millions of people have contributed to open source projects hosted on the site.

But a lot has changed since 2006. In the past nine years, many other options for hosting open source projects have popped up, along with vibrant communities of developers. It’s time to recognize that Google Code’s mission to provide open source projects a home has been accomplished by others, such as GitHub and Bitbucket.

We will be shutting down Google Code over the coming months. Starting today, the site will no longer accept new projects, but will remain functionally unchanged until August 2015. After that, project data will be read-only. Early next year, the site will shut down, but project data will be available for download in an archive format.

As the owner of the following projects, you have several options for migrating your data.

cachewolf

The simplest option would be to use the Google Code Exporter, a new tool that will allow you to export your projects directly to GitHub. Alternatively, we have documentation on how to migrate to other services — GitHub, Bitbucket, and SourceForge — manually.

For more information, please see the Google Open Source blog or contact [email protected].

-The Google Code team
 

ColleIsarco

Geowizard
Die Frage ist, ob man das nicht zur Umstellung auf Git nutzen sollte. Aus meiner Erfahrung heraus eignet sich Git besser zur verteilten Entwicklung als SVN. (Würde auch einen weiteren Umzug extrem erleichtern). Man kann die Historie aus SVN nach Git übertragen, gemacht habe ich das aber noch nie.
 

jennergruhle

Geoguru
Git ist sicher moderner und besser für verteilte Entwicklung. Wenn es unbedingt SVN bleiben soll - das wird bei Sourceforge weiter möglich sein: http://sourceforge.net/p/forge/documentation/svn/
SVN zu Git migrieren sollte auch möglich sei - Git hat ein Kommando zum Erzeugen eines neuen Repository als Klon eines SVN: http://stackoverflow.com/questions/79165/migrate-svn-repository-with-history-to-a-new-git-repository
 
OP
MiK

MiK

Geoguru
Git mag seine Vorteile haben, wenn wirklich viele Leute unkoordiniert an dem gleichen Code arbeiten. Wenn es aber eigentlich nur einen Entwicklungszweig gibt finde ich solche verteilten Systeme unpraktischer als SVN.

Von mir aus können wir aber auch gerne zu GitHub. Es gibt da ja sogar eine Schnittstelle für SVN-Clients. Das hätte auch den Vorteil, dass wir einfach den von Google Code angebotenen Export benutzen könnten. Wie es dabei mit der History aussieht weiß ich allerdings nicht.

Außerdem müssen wir auch noch schauen, dass danach unsere automatischen Build-Prozesse noch funktionieren. Zudem gibt es im Programm für Versionschecks Zugriffe direkt ins SVN, wenn ich mich richtig erinnere.

Letztlich ist arbor95 derjenige, der hauptsächlich damit arbeitet. Seine Vorlieben zählen wohl beim Umzug am meisten.
 

SammysHP

Moderator
Teammitglied
MiK schrieb:
Git mag seine Vorteile haben, wenn wirklich viele Leute unkoordiniert an dem gleichen Code arbeiten. Wenn es aber eigentlich nur einen Entwicklungszweig gibt finde ich solche verteilten Systeme unpraktischer als SVN.
Du sieht die Sache falsch: Momentan gibt es diesen einen Entwicklungszweig und eine Hand voll fester Entwickler. Mit Git würde es die Chance geben, dass sich auch andere mit dem einen oder anderen Commit beteiligen.
 
OP
MiK

MiK

Geoguru
Das ist auch mit SVN überhaupt kein Problem. Früher haben hier auch mehrere Entwickler mitgearbeitet. Wenn ich es richtig sehe, brauch man ein System wie Git erst, wenn wirklich viele mitmachen wollen, denen man evtl. auch nicht vertraut direkt im gleichen Repository zu arbeiten.

Die Entwickler sind hier ja nicht so wenige wegen SVN. Wenn jemand mitarbeiten wollte, haben wir ihm immer Zugang gegeben. Es gibt einfach zu wenig Interesse, sich an der Entwicklung zu beteiligen. Ich selbst mache ja auch quasi nichts mehr.
 

ColleIsarco

Geowizard
Ich bevorzuge Git und wenn man sich sich eingearbeitet hat, will man nicht mehr auf SVN zurück. Das Arbeiten mit Branches ist unter Git erheblich einfacher.
Letzten Endes ist es mir egal, ich kann beides.
Und wie Du schon oben geschrieben hast: Da Arbor am meisten zur Zeit macht und publiziert(!) sollte man zuerst mal seine Meinung hören.
 

arbor95

Geoguru
Mir ist es egal welchen Knopf ich drücke, Hauptsache es funktioniert und ist irgendwie transparent nachvollziehbar.
Ein Verbleib bei svn erfordert kein Überarbeiten des Build - Prozesses.
Vielleicht hat pfeffer ja noch eine Vorliebe. Bei Ihm werden die Builds schliesslich erstellt.
 

pfeffer

Geowizard
Ich finde SVN erheblich einfacher zu verstehen. Aber da ich bei einem anderen Projekt ohnehin Git nutze, spricht von mir aus nichts gegen GIT. Im Gegenteil: Ich denke GIT ist ohnehin die Zukunft.

Bei GitHub kann man auch weiterhin SVN nutzen - zumindest ich für den Build und den Versionscheck. GitHub bietet an, dass man das git-repository ber SVN auschecken kann.


Viele Grüße,
Pfeffer.
 
OP
MiK

MiK

Geoguru
Also nutzen wir dann einfach den von Google angebotenen Export des Repository nach GutHub? Soll ich das machen oder willst Du, arbor95? Steht Dir die Funktion überhaupt zur Verfügung?
Wenn ich es mache: Zu welchem Zeitpunkt würde es Euch passen?
 

pfeffer

Geowizard
mir ist egal wann. Sag einfach bescheid und gib mir ein paar Tage, damit das automatsiche Build wieder funktioniert.

Viele Grüße,
Pfeffer.
 

pfeffer

Geowizard
So, ich habe den Umzug gemacht.
neues Repository: https://github.com/cachewolf/cachewolf
Die Automatischen Builds werden jetzt auch schon automatisch von dort gezogen.

Arbor95 will morgen noch die Anleitung zur Einrichtung von Eclipse für Entwickler auf dieser Website entsprechend anpassen: http://cachewolf.aldos.de/index.php/Main/CWSelbstBauen

Entwickler legen sich einen Account bei github an und teilen mir ihren Github-Nutzernamen sowie die bei Giuthub eingetrage Email-Adresse mit, damit ich sie freischalten kann. Wem wichtig ist, dass seine alten Commits in der Committer-Statistik auf Github korrekt gezählt werden, teilt mir das ebenfalls mit, dann mache ich die Zuordnung entsprechend.

Nutzer können über https://github.com/cachewolf/cachewolf/commits/master.atom einen RSS-Feed bestellen, um immer über Änderungen (commits) bei Cachewolf informiert zu werden.

Viele Grüße,
Pfeffer.
 

ColleIsarco

Geowizard
Hallo
pfeffer schrieb:
So, ich habe den Umzug gemacht.
Vielen Dank auch von mir.

pfeffer schrieb:
Entwickler legen sich einen Account bei github an und teilen mir ihren Github-Nutzernamen sowie die bei Giuthub eingetrage Email-Adresse mit, damit ich sie freischalten kann.
Bekommst Du gerne, sobald ich den Account angelegt habe. Aber braucht es das überhaupt? Pull requests kann jeder angemeldete Benutzer erstellen und was gemerged wird obliegt Deiner Entscheidung.
Zumindest hatte ich das so verstanden.

Gruß
ColleIsarco
 

pfeffer

Geowizard
das mit den pull-requests ist eine Möglichkeit (die ich allerdings noch nicht genutzt habe). Mir scheint sie insbesondere für sehr große Projekte sinnvoll, bei denen einzelne nur mal einen Bug fixen oder für sich ein Feature implementieren, sich sonst aber nicht für das Projekt verantwortlich fühlen.

Nachteil der Pullrequests ist, dass es einen Entwickler geben muss, der die Pullrequests prüft und akzeptiert. Das scheint mir für Cachewolf mehr Aufwand zu sein als das es nutzt. Aber den Workflow mit pullreuests würde ich gern mal ausprobieren.

Man kann auch einfach - wie mit SVN - arbeiten und allen aktiven Enztwicklern Schreibrechte für das Repository geben.

Viele Grüße,
Pfeffer.
 

ColleIsarco

Geowizard
Hallo

Ich persönlich finde des durchaus vorteilhaft, Änderungen erst mal durch dritte testen zu lassen, bevor sie in den master gemerged werden. Dadurch kann man verhindern, dass sich neue Fehler in das System einschleichen oder einfach erst mal neue Dinge ausprobieren und dann entscheiden diese in das Produkt zu übernehmen.
Diese Möglichkeiten erleichtern meine Arbeit enorm. Aber ja, es muß einer entscheiden, ob ein Request angenommen wird oder nicht und der hat Mehrarbeit.
Ich empfehle einfach: Ausprobieren, die beste Arbeitsweise stellt sich mit der Zeit von alleine ein.

Gruß
ColleIsarco
 

Kalli

Geowizard
Habe jetzt auch ein bisschen mit eclipse und git getestet und eine kleine Änderung eingecheckt, dabei war mir aufgefallen, dass die Umlaute komisch aussahen, also noch mal zurückgedreht, Zeichensatz anders eingestellt und neuer Versuch. Jetzt sieht es ganz gut aus.

Edit: Kann das sein, dass die Webseite auf github etwas hinterherhinkt? Auf meinem Client habe ich die Änderung über eclipse ziemlich zeitgleich angezeigt bekommen.
 

pfeffer

Geowizard
nein - die Website ist immer sofort aktuell.
Vermutlich liegt es an Folgendem:
Bei Git hat jeder eine komplette Kopie des repositorys lokal in dem versteckten Verzeichnis ".git".
Wenn man bei Git nun commitet, wird nur in das lokale repository commited. Anschließend muss man noch "push" machen, damit die Änderungen aus dem lokalen repository zu github übertragen werden.

Viele Grüße,
Pfeffer.

PS: Bei Tortoise erscheint nach dem commit ein Dialog, bei dem links unten ein Knopf "push" ist.
 

Kalli

Geowizard
OK, das erklärt auch, warum ich zwei Buttons hatte, einmal "Commit" und dann "Commit and Push" (oder so ähnlich).

Pushen kann ich noch nicht, da ich noch nicht darf. Macht auch erst Sinn, wenn der Umzug komplett gelaufen ist, ansonsten müsste man ja zwei Repos pflegen.
 
Oben