Welche Source Control?

[Captain Unsichtbar]

Wie der Titel schon sagt beschäftigte ich mich momentan mit der Frage einer geeigneten Source Control für meine UE4-Arbeiten. Das Problem ist allerdings: von Haus aus bietet UE4 nur Unterstützung für Perforce und SVN, die Frage wäre dann halt wie gross der Aufwand wäre ggf. andere Source Controls einzubauen. Ist SVN noch zu empfehlen? Bei Perforce gibt es ja eine Free-Version für eine maximale Teamgrösse von 5 Leuten.

Gibt es hier Leute die Erfahrungen mit den unterschiedlichen Source Controls haben?

Achso und eine einigermassen nutzbare grafische Oberfläche sollte es auch haben. Ich bin kein Coder, bloss ein Designer, der es sich einfacher machen möchte.

[Unkreativer]

Ich habe Erfahrung mit Subversion und Git (das ist doch, was du meinst?). Allerdings ist meine Erfahrung mit Subversion fast zehn Jahre her. In Erinnerung geblieben ist mir, dass Subversion einfacher ging, weil das ins Kontextmenü im Explorer integriert war. Rechtsklick und 'Upload' oder 'Alte Version wiederherstellen' und die Sache war gelöst.
Mit Git ist es deutlich aufwendiger, wenn man nur Standardgit über Konsole hat. Da kann man sich auch öfter mal was kaputtmachen, was man nur mit Erfahrung wieder hinkriegt.
Der Vorteil von Git ist, dass man das komplette Projekt versioniert und nicht nur einzelne Dateien. Wenn man sich darauf einigt, dass man nur kompilierbare Projekte hochlädt, kann man jeden Stand immer kompilieren. Wenn die Dateien einzeln verwaltet werden, kann es sein, dass Dateien grundsätzlich kompilierbar sind, aber unterschiedliche Versionen haben, so dass das Projekt insgesamt nicht erstellbar ist.

[Captain Unsichtbar]

Jep genau das meinte ich. Ich bin nur etwas verunsichert, weil ich jetzt schon an mehreren Orten gelesen habe, Subversion sei veraltet bzw. werde nicht mehr weiterentwickelt. Da es in der Engine selbst integriert ist wäre die Nutzung mit Subversion ziemlich einfach, da es dafür extra ein Menü "Source Control" gibt.
Die Frage bei Subversion wäre auch noch, ob es dafür Host-Anbieter gibt oder ob man sich selber einen Server für das Repository aufsetzen muss?

Hmm, ich frage mich gerade, kann das nicht auch ein Nachteil sein, wenn das ganze Projekt versioniert wird? Mir ist vor allem Branching wichtig, damit unterschiedliche Leute unabhängig an verschiedenen Features arbeiten können. Aber wenn ich das ganze Projekt versioniere, wird dann nicht die Zurückverfolgung einzelner Änderungen schwieriger?

Beispiel:
Version 1 beinhaltet Feature A und B
Version 2 ist ein neuer Merge mit den zusätzlichen Features C und D. Also neu: A, B, C und D.

Wie gehe ich jetzt zurück und bekomme eine Version mit nur A, B, und D, wenn zb nur C fehlerhaft o.ä. war?

Zum Thema Kompilieren: grundsätzlich ist das Projekt als ganzes immer kompilierbar, da am Source Code der Engine selbst zurzeit keine Änderungen geplant sind. Durch unvollständigen Code würden nur einzelne Features nicht funktionieren und womöglich während der Runtime abschmieren. Aber da gehe ich natürlich davon aus, dass der Code erst hochgeladen wird, wenn die Arbeit am jeweiligen Feature soweit fertig ist. Deshalb ja auch das Branching, damit jeder die Features unabhängig vom Hauptbuild testen kann.

[Unkreativer]

Hmm, ich frage mich gerade, kann das nicht auch ein Nachteil sein, wenn das ganze Projekt versioniert wird? Mir ist vor allem Branching wichtig, damit unterschiedliche Leute unabhängig an verschiedenen Features arbeiten können. Aber wenn ich das ganze Projekt versioniere, wird dann nicht die Zurückverfolgung einzelner Änderungen schwieriger?

Beispiel:
Version 1 beinhaltet Feature A und B
Version 2 ist ein neuer Merge mit den zusätzlichen Features C und D. Also neu: A, B, C und D.

Wie gehe ich jetzt zurück und bekomme eine Version mit nur A, B, und D, wenn zb nur C fehlerhaft o.ä. war?

Erfahrungsgemäß gibt es für alles irgendeine Funktion von Git, allerdings ist das oft sehr kompliziert und (auch) deshalb kann ich dir nicht sagen wie. Wir haben sehr viel mit Verzweigungen gearbeitet und die später zusammengeführt. Das heißt, es kam nicht eine Version mit C und D dazu, sondern eine Version mit C und eine mit D. Wenn es Probleme gab, haben wir das rückgängig gemacht und eben nur D eingefügt.
Allerdings war das auch auf der Uni. Erfahrung mit großen Gruppen habe ich nicht.

[ABstronaut]

In Git arbeitet man halt mit Branches. Sie sind einfach Zeiger auf bestimmte Commits, also Änderungen. Commits verweisen dann auf andere Commits, usw.
Ich denke, dass unter Git sowohl deine "Features", als auch Versionen Branches wären, von denen dann andere Branches abzweigen bzw. in sie hineingemerged werden. Git ist schon sehr mächtiges Wekzeug und entspricht, meines Wissens, dem Stand der Technik und wird in sehr vielen Projekten verwendet. Dafür gibt es dann z. B. Atlassian SourceTree als grafische Oberfläche.

Wie man das macht, hängt aber sehr vom konkreten Fall ab. Es gibt meistens mehrere Wege, dazu würde ich dir empfehlen, dass du dich ggf. vorab schon ein wenig beschäftigst mit den verschiedenen Systemen, um ihre Grundprinzipien zu verstehen, was gerade bei Git nicht unwichtig ist.
Hier ein Artikel, der sich mit dem im Beispiel erwähnten Thema beschäftigt. Ich schicke ihn dir nur, damit du einen Eindruck davon bekommst, wie die Sachen in Git laufen, kann u. U. etwas sanspruchsvoller sein, wenn man noch nicht mit Git gearbeitet hat. Da geht es um das Rückgängigmachen eines Merges. Es führen, wie gesagt, mehrere Wege zum Ziel.
Um das System sinvoll zu nutzen, braucht es einer gewissen Einarbeitung, die sich aber gerade dann auszahlt, falls Probleme auftreten. Bei Git ist es leider mit der reinen Installation nicht getan.

[Pierre]

Wah, Leute - meint ihr nicht dass es für solche Fragen besseren Input gibt in darauf spezialisierten Boards?

Ich nehm bis auf weiteres SVN, weil das eine klassische Client-Server Architektur hat, d.h. ich weiss wo mein Gelumpe liegt: in der Repo auf dem Server, und sonst nirgens. Und mit so einer Architektur weiss ich bisher nix neueres/besseres.

Die allerlei neueren, hypigeren Sachen sind m.W. eher dezentral organisiert, also "cloudiger". Mein Zeug liegt dann also *irgendwo* oder *überall*, und ich muss selber ständig Disziplin wahren, was ich wo hinlege. Das gefällt offenbar den Linuxjungs, weil sie eh denselben Chaoshaufen in ihrem ganzen OS haben.

Die zweitwichtigste Frage dürfte sein, was die Zulieferer verwenden. Bei vielen Projekten liegt alles auf einem GitHub rum, und da wird es sinnvoll sein, das Spiel genauso mitzuspielen.

Eher unwichtiger scheint mir, wie welche Merges usw. gehen - denn da können die Tools weitgehend alle alles, man muss nur rausfinden wie man es jeweils strategisch am sinnvollsten macht.

Klickibunti ist nochmal ein anderes Thema, aber dazu weiss ich nichts, weil ich die KZ als grundlegende Methode sehe und Mäuseschubsen als darübergelegtes nice-to-have.

[Pierre]

Die Frage bei Subversion wäre auch noch, ob es dafür Host-Anbieter gibt oder ob man sich selber einen Server für das Repository aufsetzen muss?

Sollte es geben, zB assembla.com

[ABstronaut]

Wah, Leute - meint ihr nicht dass es für solche Fragen besseren Input gibt in darauf spezialisierten Boards?

Ich denke, dass der Threadstarter auch in Spezialforen keine Antwort finden wird, welche Source Control für sein konkretes Projekt richtig ist. Denn als Externer weiß man nicht genug über das Projekt, um es vernünftig beurteilen zu können. Letztendlich muss man vor Ort jemanden haben, der sich auskennt und die SC aufsetzt.

[ABstronaut]

Die allerlei neueren, hypigeren Sachen sind m.W. eher dezentral organisiert, also "cloudiger". Mein Zeug liegt dann also *irgendwo* oder *überall*, und ich muss selber ständig Disziplin wahren, was ich wo hinlege.

Mag sein, dass es solche Systeme auch gibt, Frage ist, welches gemeint ist. Ich kann bzgl. Git sagen, dass man da immer genau weiß, wo die Sachen liegen - nämlich auf der eigenen Festplatte (im eigenen Repository). Solange man sie nicht bewusst und explizit auf ein entferntes Repository (Speicherplatz) pusht (kopiert). Bei Git sehe ich den Nachteil zumindest nicht.

[Captain Unsichtbar]

Ich denke, dass unter Git sowohl deine "Features", als auch Versionen Branches wären, von denen dann andere Branches abzweigen bzw. in sie hineingemerged werden. Git ist schon sehr mächtiges Wekzeug und entspricht, meines Wissens, dem Stand der Technik und wird in sehr vielen Projekten verwendet. Dafür gibt es dann z. B. Atlassian SourceTree als grafische Oberfläche.

Wie man das macht, hängt aber sehr vom konkreten Fall ab. Es gibt meistens mehrere Wege, dazu würde ich dir empfehlen, dass du dich ggf. vorab schon ein wenig beschäftigst mit den verschiedenen Systemen, um ihre Grundprinzipien zu verstehen, was gerade bei Git nicht unwichtig ist.

Ja ich habe da etwas gelesen zum Feature Branch Workflow respektive Gitflow Workflow. Letztere wurde dafür ausdrücklich empfohlen.

Ich nehm bis auf weiteres SVN, weil das eine klassische Client-Server Architektur hat, d.h. ich weiss wo mein Gelumpe liegt: in der Repo auf dem Server, und sonst nirgens. Und mit so einer Architektur weiss ich bisher nix neueres/besseres.

Die allerlei neueren, hypigeren Sachen sind m.W. eher dezentral organisiert, also "cloudiger". Mein Zeug liegt dann also *irgendwo* oder *überall*, und ich muss selber ständig Disziplin wahren, was ich wo hinlege. Das gefällt offenbar den Linuxjungs, weil sie eh denselben Chaoshaufen in ihrem ganzen OS haben.

Das wäre eben auch mein Punkt, weshalb mir SVN "sympathischer" erscheint.
Das Problem, das ich mit Git momentan habe, ist dass es mit Git alleine noch nicht getan ist, dazu käme dann noch Extensions wie git-lfs sowie optional git-flow.

Die zweitwichtigste Frage dürfte sein, was die Zulieferer verwenden. Bei vielen Projekten liegt alles auf einem GitHub rum, und da wird es sinnvoll sein, das Spiel genauso mitzuspielen.

Naja GitHub ist ja nur für Open-Source, das trifft bei mir definitiv nicht zu. Und GitHub Enterprise wird sich kaum lohnen. Wenn ich den Aufwand betrachte.

Klickibunti ist nochmal ein anderes Thema, aber dazu weiss ich nichts, weil ich die KZ als grundlegende Methode sehe und Mäuseschubsen als darübergelegtes nice-to-have.

Gut, über die despektierliche Verwendung dieses Begriffs habe ich anderen Orts ja schon mal geschrieben. Ich bin hauptsächlich Designer, teilweise meinetwegen auch Technical Artist. Gestaltung gehört zu meiner Kernkompetenz. Sehe ich deshalb alles andere als sinnlos. Nun gut, Coder übertreiben ihre eigene Wichtigkeit ja gerne mal. Kann ich mit leben.

[Genosse Premier]

Mir wäre neu, dass ein bestimmtes source-code Paket nur bestimmte Software zur Versionskontrolle unterstützt. Man kann generell immer alles verwenden. Ich kenne die ue4 nicht, aber es wäre schlimm, wenn es damit anders wäre

Ah, und um die Diskussion anzuheizen: Immer Git nehmen!

[Captain Unsichtbar]

Mir wäre neu, dass ein bestimmtes source-code Paket nur bestimmte Software zur Versionskontrolle unterstützt. Man kann generell immer alles verwenden. Ich kenne die ue4 nicht, aber es wäre schlimm, wenn es damit anders wäre

Ah, und um die Diskussion anzuheizen: Immer Git nehmen!

Nein, das habe ich so auch gar nicht gesagt. Perforce und SVN sind einfach als Default bereits "built-in". Via Plugin nehme ich an, und können deshalb direkt aus der Engine heraus verwendet werden, was für einen schnellen Worklflow halt schon irgendwie von Vorteil ist. Vorallem bekommt man dadurch Statusicons bei den Assets angezeigt. Das ist insofern spannend, weil nicht das ganze Projekt gepusht bzw. gezogen werden muss.

[Pierre]

Die allerlei neueren, hypigeren Sachen sind m.W. eher dezentral organisiert, also "cloudiger". Mein Zeug liegt dann also *irgendwo* oder *überall*, und ich muss selber ständig Disziplin wahren, was ich wo hinlege.

Mag sein, dass es solche Systeme auch gibt, Frage ist, welches gemeint ist. Ich kann bzgl. Git sagen, dass man da immer genau weiß, wo die Sachen liegen - nämlich auf der eigenen Festplatte (im eigenen Repository). Solange man sie nicht bewusst und explizit auf ein entferntes Repository (Speicherplatz) pusht (kopiert). Bei Git sehe ich den Nachteil zumindest nicht.

Okay, wenn Du nur eine Festplatte hast, dann erübrigt sich diese Frage.
Ich hab ein paar mehr, und einige (virtuelle) Instanzen stehen auch mit echter IP voll zugänglich im Internet. Und da wird es dann schon etwas lustiger, und man muss ein bischen über die Infrastruktur nachdenken.

[Pierre]

Die zweitwichtigste Frage dürfte sein, was die Zulieferer verwenden. Bei vielen Projekten liegt alles auf einem GitHub rum, und da wird es sinnvoll sein, das Spiel genauso mitzuspielen.

Naja GitHub ist ja nur für Open-Source, das trifft bei mir definitiv nicht zu. Und GitHub Enterprise wird sich kaum lohnen. Wenn ich den Aufwand betrachte.

"Zulieferer" meinte ich anders. Ich mache zB in Ruby, und da liegen schonmal allerlei Bibliotheken ("gems") auf GitHub oder irgendsowo. D.h. wenn ich an denen dengeln muss, sollte ich Git verstanden haben (hab ich aber nicht ).

Klickibunti ist nochmal ein anderes Thema, aber dazu weiss ich nichts, weil ich die KZ als grundlegende Methode sehe und Mäuseschubsen als darübergelegtes nice-to-have.

Gut, über die despektierliche Verwendung dieses Begriffs habe ich anderen Orts ja schon mal geschrieben. Ich bin hauptsächlich Designer, teilweise meinetwegen auch Technical Artist. Gestaltung gehört zu meiner Kernkompetenz. Sehe ich deshalb alles andere als sinnlos. Nun gut, Coder übertreiben ihre eigene Wichtigkeit ja gerne mal. Kann ich mit leben.

Sorry, das heisst nur: davon hab ich keine Ahnung (und will auch keine haben), kann Dir also in dem Punkt kaum weiterhelfen.
Mit Codern hab ich nix zu tun, ich mach eigentlich Infrastruktur für Rechenzentren (Connectivity, Mengengerüste, solches zeug).
Da ist man eher so ein Universaldilettant, der bei allem ungefähr wissen sollte wie es zusammenhängt - und deshalb froh über alles, was man gedanklich "weglassen" kann - und Grafik kann man auf der Ebene ungestraft weglassen...

[Captain Unsichtbar]

"Zulieferer" meinte ich anders. Ich mache zB in Ruby, und da liegen schonmal alle Bibliotheken ("gems") auf GitHub. D.h. wenn ich an denen dengeln muss, sollte ich Git verstanden haben.

Jetzt verstehe ich es dafür noch weniger als zuvor. Aber zusätzliches Zeugs bedarf es in meinem Falle eh nicht. Es geht wirklich nur darum das Projekt zu teilen, damit im Team daran gearbeitet werden kann.

Sorry, das heisst nur: davon hab ich keine Ahnung (und will auch keine haben), kann Dir also in dem Punkt kaum weiterhelfen.
Mit Codern hab ich nix zu tun, ich mach eigentlich Infrastruktur für Rechenzentren (Connectivity, Mengengerüste, solches zeug).
Da ist man eher so ein Universaldilettant, der bei allem ungefähr wissen sollte wie es zusammenhängt - und deshalb froh über alles, was man gedanklich "weglassen" kann - und Grafik kann man auf der Ebene ungestraft weglassen...

Ach keine Sorge, das war weniger böse gemeint, als es möglicherweise rüber kam. Deswegen eigentlich auch die Smileys am Schluss zur Auflockerung.

[Pierre]

Jetzt verstehe ich es dafür noch weniger als zuvor. Aber zusätzliches Zeugs bedarf es in meinem Falle eh nicht. Es geht wirklich nur darum das Projekt zu teilen, damit im Team daran gearbeitet werden kann.

Prima, ein Problem weniger. Dann täte ich das nehmen was offenbar schon vorgesehen ist, weil damit dann vermutlich die meisten arbeiten. Also vorrangig SVN - das Perforce ist vermutlich deshalb vorgesehen, weil manche Firmen keine OpenSource mögen und auf kommerziellem Support bestehen.

[Captain Unsichtbar]

Prima, ein Problem weniger. Dann täte ich das nehmen was offenbar schon vorgesehen ist, weil damit dann vermutlich die meisten arbeiten. Also vorrangig SVN - das Perforce ist vermutlich deshalb vorgesehen, weil manche Firmen keine OpenSource mögen und auf kommerziellem Support bestehen.

Ja werde ich jetzt wahrscheinlich tatsächlich probieren. Ich war halt nur anfangs irritiert von der ganzen Git-vs-SVN-Diskussion im Netz. Und offenbar geht die hier ja weiter.

Naja gut, das kann ich auch irgendwo nachvollziehen. Bei einer 100m Produktion bist du halt auf professionellen 24h-Stunden-Support angewiesen, am besten mit persönlicher Ansprechsperson. Ich hab schon erlebt, was es heisst schlechten Support zu haben. Da sitzt dann das ganze Team Däumchendrehend rum weil nichts mehr geht.

[Arsonist]

Habe in meinem letzten Job mit SVN gearbeitet: SVN + Mantis + Eclipse = <3

In meiner neuen Firma nutzen wir GIT + R Studio + PyCharm.

SVN und Git sind durchaus verschieden aber tun es gut. Sich an die Kommandozeile zu gewöhnen lohnt sich! Bin damit locker 5x schneller als mit dem GUI. Würde an deiner Stelle Git verwenden, aber prinzipiell ist es egal da bin ich echt emotionslos.