Warum wird der Quellcode auf Codeplex bereitgestellt?

[DrakonAlpha]

Warum wird eigentlich der offene Quellcode zu "Birth of the Empires" auf Codeplex bereitgestellt? Warum überhaupt? Warum speziell dort?

[chrisfirefox]

Also wenn ich raten wüsste, würde ich sagen "weils schon immer so war" . Ich persönlich hatte letztens gna.org gefunden und vorgeschlagen, kann das selbe, ist aber gefühlt Faktor 20 schneller, aber halt nicht so "hübsch" .

[Anonymissimus]

gna ist keine gute Idee; die sind ziemlich schlecht maintained und so. Bei BfW gibts immer mal Überlegungen von dort weg umzuziehen.
Wenn schon, dann ist glaube github eine gute Wahl. Bei BfW war das in der engen Wahl.

[chrisfirefox]

Github heißt halt weg von Subversion, ich hab schon mit Git und Mercurial gearbeitet, in der Firma setzen wir seit Jahren Subversion ein. Ich persönlich finde es äußerst gewöhnungsbedürftig, dass ein Commit bei den erstgenannten nur lokal passiert, und man erst durch den "push" das Ganze auch tatsächlich öffentlich macht, bei Subversion heißt Commit halt "für alle zugänglich machen". Ansonsten bin ich da aber ehrlichgesagt ambivalent eingestellt, Git ist lokal bei den Vergleichen natürlich massiv schneller, weil das gesamte Repository lokal liegt, und natürlich dadurch auch überhaupt nicht auf den Server angewiesen, notfalls kann man sogar "peer 2 peer" arbeiten. Insgesamt kommt mir der ganze Ansatz aber sehr... wie soll ich sagen, chaotisch vor?

Außerdem weiß ich nicht, inwieweit ein Export der Codeplex-SVN-History überhaupt machbar ist, ob also ein Umstieg überhaupt denkbar wäre, ohne die ganze History komplett zu verlieren.

[RedAdder]

Das verteilte Arbeiten finde ich eigentlich gut an git, da hat quasi jeder Benutzer eine Sicherheitskopie des origins. Kann sonst leicht passieren bei svn, dass das zentrale Archiv verloren geht oder nicht erreichbar ist.

Außerdem darf jeder committen, lokal eben, nur darf vielleicht nicht jeder zum origin pushen.

[chrisfirefox]

Das mag jetzt komisch klingen, aber scheinbar bin ich zu blöd für das Mergen, das man dann jedes Mal bei Git oder Mercurial hat, wenn zufällig mal zwei Leute committed und dann gepusht haben, mir ist das jedes Mal nur hoffnungslos kompliziert vorgekommen. Natürlich ist man bei einem VCS vom Server abghängig, den man bei einem DVCS theoretisch nicht braucht. Praktisch ist dieser "jeder kann committen"-Ansatz halt wie gesagt ein sehr chaotischer Ansatz mit seinen persönlichen Forks, lokalen Repositories und Whatnot. Ist halt auch viel eine Philosophiefrage, dem Open Source Gedanken kommt Git sicher entgegen, dem Bedürfnis, eine "zentrale" Version zu haben, von der tatsächlich jeder aus auch "einfach" arbeiten kann, und die einfach auf einem gemeinsamen und gleichen Stand gehalten werden kann finde ich eher nicht. Wie gesagt, Philosophiefrage.

Ich nutze Mercurial gerne lokal, wenn ich ein kleines Projekt habe, an dem ich nur alleine arbeite. Sobald aber mehr als eine Person an einem Projekt arbeitet, bin ich bisher überhaupt nicht überzeugt davon und meide es wie nur was. Und dass ein Repository mit Binärdaten (wie zB Bildern) gleich mal ewig groß wird, weil natürlich alle Versionen der Binärdaten übertragen werden müssen und nicht nur die letzte wie bei einem zentralen VCS trägt jetzt nicht gerade zur besseren Nutzbarkeit von Git/Mercurial bei finde ich .

[Anonymissimus]

Das mag jetzt komisch klingen, aber scheinbar bin ich zu blöd für das Mergen, das man dann jedes Mal bei Git oder Mercurial hat, wenn zufällig mal zwei Leute committed und dann gepusht haben, mir ist das jedes Mal nur hoffnungslos kompliziert vorgekommen.

Bist du locks gewohnt ?
Mit der Zeit lernt man mit Konflikten umzugehen würd ich sagen. Leider gibt es viele die mehr oder weniger künstlich durch git erzeugt werden (zB Dateiende und so). Am effektivsten ist es sie von vornherein zu vermeiden. Meistens ists kein echter Konflikt; wenn doch dann mach ich nen extra branch auf und hohl mir da die changesets runter und schaue mir die diff des "feindlichen" commits an, welche hoffentlich übersichtlich ist.

[chrisfirefox]

Locks weniger. Aber ich bin es gewöhnt, dass ich mich auf den Stand im Repository verlassen kann, bei den DVCS die ich bisher gesehen habe, war das immer fürchterlich umständlich. Ich hab da in erster Linie Tortoise* als Client verwendet, und irgendwie kommt mir das bei SVN wesentlich logischer vor. Naja egal, wie gesagt, sowohl SVN als auch die DVCS haben ihre Vor- und Nachteile. Angeblich kann man sogar die gesamte History exportieren ab SVN-Serverversion 1.7, d.h. sogar die könnten wir behalten...

[Anonymissimus]

Locks weniger. Aber ich bin es gewöhnt, dass ich mich auf den Stand im Repository verlassen kann,

Aber ist das nicht genau was einen Lock ausmacht ? (Kenne locks bisher nicht.) Ich meine, man verbietet doch damit allen anderen, die diese Datei gerade würden modifizieren wollen, das zu tun, sodass keine Konflikte entstehen können ?
In einer Firma funzt so etwas vermutlich einiges besser als bei open source; vllt kann es sein dass einer sich nen lock hohlt und dann verschwindet und man muss warten bis Puste das Problem endlich beseitigt ?

[Sir Pustekuchen]

Zur Ausgangsfrage:
Ich fand es auf den ersten Blick gut. Ich muss auch zugeben, dass ich mich nicht groß nach Alternativen umgeschaut habe. SVN nutzte ich schon vorher, von daher fand ich Codeplex gut. Ich konnte alles einrichten und hochladen, ohne mich extra in eine neue Materie einarbeiten zu müssen. Das will ich jetzt auch nicht, von daher möchte ich das Projekt bei Codeplex belassen.

[chrisfirefox]

Sir Pustekuchen, gna.org war mir aufgefallen, weil es eben auch svn anbietet - wie oben schon geschrieben bin ich auch kein Fan von diesem "neumodischen" DVCS-Zeugs und würde auch gerne weiterhin mit SVN arbeiten. Ich hab mich auch schon schlau gemacht, und bei einem SVN-Server 1.6 lässt sich ein Projekt mit einigen kleineren Einschränkungen inklusive Historie ohne Serverzugang exportieren. Bei Server 1.7 gehts sogar ohne Einschränkungen. Leider konnte ich noch nicht rausfinden, welchen Server Codeplex im Einsatz hat.

Aber ganz ehrlich, die Servicequali von Codeplex ist meiner Meinung nach wirklich nicht gut, und eine Alternative wäre dazu wirklich mal zumindest auszukundschaften finde ich .

[Anonymissimus]

Aber ganz ehrlich, die Servicequali von Codeplex ist meiner Meinung nach wirklich nicht gut

Ich stimme da voll zu. Ich kenne sourceforge, gna und ein bissl github; keine dieser drei scheint so oft "off" zu sein wie codeplex. Und es gibt da ja auch noch viewtopic.php?f=7&t=1741&p=27616&hilit= ... c08#p27616

[rainer]

mal eine blöde Frage von mir als Laien: Also könnte man codeplex inkl. Historie irgendwohin testweise exportieren und dann nur uns allen sagen, wie man darauf zugreifen kann (probieren geht über studieren...)

Könnte mir vorstellen, dass, wenn es nicht viel Aufwand ist, wir Puste überzeugen können:
- lokal auf seinem PC hat er (und wir) schnell ein Programmchen installiert.
- ich verstehe auch, dass Puste dann die (alleinigen) ADMIN-Rechte am neuen Server haben will:
--- das Baby und der meisten Code ist ja sein Werk und er gibt ja seinen Namen her für BotE
--- die Einarbeitung in den neuen SVN sollte für ihn nicht turboschwierig/-aufwändig sein
- der neue Platz den gleichen Umfang (Committen, Historie usw) bietet

wenn's Puste dann doch nicht gefällt, ist es doch auch relativ schnell wieder gelöscht

[Sir Pustekuchen]

Ich habe ja immernoch die Hoffnung, das Microsoft den Dienst stabiler hinbekommt. Und bei Microsoft kann ich sicher sein, dass alles seine Ordnung hat (Lizenz, Geheimhaltung, Sicherheit usw.). Das kann ich bei mir unbekannten Anbietern nicht beurteilen.

Falls der Umzug nicht kompliziert ist, dann stelle ich mich aber nicht gegen den Wunsch der Community.

[Anonymissimus]

Das Hauptproblem (wie bei allem) ist dass irgendwer die Arbeit machen muss; ich hab da kein Plan was mich betrifft.