Können Künstler in einer Open-Source-Umgebung realistisch mit (verteiltem) Versionskontrolle umgehen?

Question

Hey, ich arbeite in der Projektmanagementabteilung eines Open-Source-Spiels. Im Moment verwenden wir SVN zur Versionskontrolle und speichern Code und Assets im selben Repository. Die Quellversionen der Assets (Modelle, Texturen) befinden sich in einem separaten Media-Zweig, während die gerenderten Versionen der Assets (wir arbeiten an einem isometrischen 2D-Spiel, daher verwenden wir tatsächlich gerenderte 2D-Bilder der 3D-Modelle im Spiel) nahe am Code liegen, da sie an Ort und Stelle sein müssen, um das Spiel auszuführen.

Unsere Künstler hatten Schwierigkeiten, mit der Verwendung von Subversion zu beginnen und das Konzept der Versionskontrolle im Allgemeinen zu verstehen. Im Moment besteht das Projekt größtenteils aus Programmierern, und wir erwägen, von SVN auf verteilte Versionskontrolle umzusteigen, um das Arbeiten mit Zweigen (und dem damit verbundenen Merging-Prozess) und das Einreichen von Patches zu erleichtern. Wir haben noch keine Entscheidung darüber getroffen, welches DVCS wir verwenden werden, aber höchstwahrscheinlich werden wir entweder Mercurial oder Git verwenden.

Während verteilte Versionskontrolle großartig für Entwickler mit technischem Hintergrund ist, erscheint sie möglicherweise übermäßig komplex und kompliziert für Künstler und andere möglicherweise weniger technikaffine Entwickler.

Also bin ich auf der Suche nach allen Arten von Ratschlägen, wie wir den Versionskontroll-Workflow für Künstler vereinfachen könnten. Beachten Sie, dass die Verwendung von etwas wie Perforce, unabhängig davon, wie gut es für den Job geeignet sein könnte, keine Option für ein kostenloses Open-Source-Projekt ist. Daher bin ich eher auf der Suche nach Ratschlägen, Tutorials, Projekttools, die es für Künstler leicht machen, verteilte Versionskontrolle zu verstehen, insbesondere Hg und/oder Git.

Ist es überhaupt sinnvoll, diesen Weg einzuschlagen und zu versuchen, die Künstler dazu zu bringen, verteilte Versionskontrolle zu verwenden? Wir könnten weiterhin die Quellversionen der Assets (Texturen, Modelle) in unserem bestehenden SVN-Repository speichern. Aber wir müssten immer noch eine Lösung für die Assets finden, die benötigt werden, um das Spiel auszuführen, da sie nahe am Code in der Versionskontrolle liegen sollten.

Es gibt eine Reihe großartiger DVCS-Anleitungen, z. B. das Hginit-Tutorial. Allerdings waren die von mir gefundenen alle für Programmierer geschrieben. Es ist großartig, dass sie jetzt problemlos lokal committen, das volle Potenzial von Zweigen nutzen und ihre Änderungen ohne allzu großen Aufwand zurückführen können. Dies könnte jedoch für Künstler nicht vorteilhaft, sondern eher übermäßig komplex und beängstigend sein. Kennen Sie zufällig ein DVCS-Tutorial, das für Künstler als primäre Zielgruppe geschrieben wurde?

Wir verwenden auch Trac zu Projektmanagementzwecken, also wenn Sie einen Trac-Plugin kennen, der künstlerfreundlich ist, lassen Sie es mich bitte wissen :-)

Answer 1

Es hört sich für mich so an, als hättest du schon genug Schwierigkeiten damit, die Künstler dazu zu bringen, SVN zu verwenden, und DVCS auf sie zu drängen, wäre ein verlorener Kampf. Vielleicht gibt es eine Möglichkeit, das DVCS mit SVN-Check-ins zu aktualisieren, damit das DVCS auf dem neuesten Stand bleibt mit SVN?

In Bezug auf die Übernahme von SVN denke ich, dass es wirklich bei Menschen gut ankommt, wenn sie es als etwas betrachten, das sie brauchen (oder ohne das sie nicht leben können), anstatt etwas, das ihnen 'die Obrigkeit' aufzwingt. Wenn sie sehen könnten, wie sie von dem Tool profitieren können (d. h. Rückkehr zu früheren Revisionen usw.), wären sie vielleicht eher bereit, es anzunehmen. Ich weiß jedoch nicht, ob SVN einem Künstler den gleichen Nutzen bringen kann wie einem Programmierer.

Als Programmierer, der sowohl mit als auch ohne Versionskontrollsystem gearbeitet hat, kann ich ehrlich sagen, dass die Welt des Versionskontrollsystems ein viel besserer Ort ist, und ich werde nie in eine Welt ohne zurückkehren.