¿Pueden los artistas enfrentarse de forma realista al control de versiones (distribuidas) en un entorno de código abierto?

Question

Heya, estoy trabajando en el departamento de gestión de proyectos de un juego de código abierto. En este momento estamos usando SVN para control de versiones y código de tienda y activos en el mismo repositorio. versiones de código de activos (modelos, texturas) residen en una rama de prensa por separado, mientras que las versiones procesadas de los activos (estamos trabajando en un juego 2d isométrica, así que en realidad usar imágenes 2D prestados de los modelos 3D en el juego) residen cerca del código, ya que son necesarios para ejecutar el juego.

Nuestros artistas tuvieron dificultades para comenzar a utilizar Subversion y para familiarizarse con el concepto de control de versiones en general. En este momento el proyecto está compuesta principalmente por programadores y estamos considerando la posibilidad de pasar de SVN para el control de versiones distribuido para facilitar el trabajo con ramas (y el proceso de fusión asociada) y el envío de parches. Todavía no hemos tomado una decisión sobre qué DVCS usar, pero lo más probable es que terminemos usando Mercurial o Git.

Mientras que el control de versiones distribuidas es ideal para desarrolladores con una formación técnica, puede parecer demasiado complejo y complicado para artistas y otros desarrolladores de tecnologías menos prolíficas.

Así que estoy buscando todo tipo de consejos sobre cómo podemos facilitar el flujo de trabajo de control de versiones para los artistas. Tenga en cuenta que el uso de algo así como Perforce, independientemente de lo que podría ser adecuado para el trabajo, no es una opción para la conexión del proyecto de código abierto cargo. Así que estoy más o menos bien en busca de consejos, tutoriales, herramientas de proyectos que hacen que sea fácil para los artistas para envolver su cabeza alrededor distribuido de control de versiones, especialmente Hg y/o Git.

¿Vale la pena recorrer esa ruta e intentar que los artistas utilicen el control de versión distribuida? Podríamos continuar almacenando las versiones de origen de los activos (texturas, modelos) en nuestro repositorio SVN existente. Pero aún tendríamos que encontrar una solución para los activos que se necesitan para ejecutar el juego, ya que deberían residir cerca del código en el control de la versión.

Hay una gran cantidad de excelentes guías DVCS disponibles, por ejemplo. el Hginit tutorial. Sin embargo, los que encontré fueron escritos para programadores. Es genial que ahora puedan comprometerse fácilmente a nivel local, usar todo el potencial de las sucursales y fusionar sus cambios sin demasiada molestia. Pero esto podría no ser beneficioso para los artistas, sino demasiado complejo y aterrador para ellos. ¿Conoces un tutorial de DVCS que fue escrito para artistas como el público objetivo principal?

También estamos utilizando Trac con fines de gestión de proyectos, por lo que si usted sabe de un plugin Trac que es artista amable, que me haga saber, así :-)

Answer 1

Ni siquiera estoy seguro que los programadores pueden hacer frente de manera realista con control de versiones distribuidas. Como prueba, ofrezco la cantidad de preguntas sobre control de versiones distribuidas en Stack Overflow.

Mi sugerencia sería dar a los artistas dos listas de verificación o hojas de trucos. Uno para realizar trabajos artísticos y otro para recuperar obras de arte. Estas hojas de trampas serían específicas para su entorno de trabajo.

Si un artista quiere entender qué pasa con el control de fuente, uno de los programadores puede explicar los detalles.

Ha sido mi experiencia que la mayoría de la gente quiere hacer su trabajo, y no le importa qué. Solo les importa cómo.

Answer 2

Los siguientes son buena introducción visual para control de versiones y mercurial.

Trate de ver, si ayuda a hacerlo más fácil de entender.Me resultaría muy difícil usar algo que no puedo envolver en mi cabeza.

Así que aquí están algunas buenas introducciones visuales:

• http://betterexplained.com/articles/a-visual-guide-to-version-control/
• http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

Git expone un modelo más detallado, que es del agrado de muchos programadores. Mercurial proporciona un subconjunto más limpio y más pequeño de conceptos para tratar. Creo que Mercurial será más adecuado para su propósito.

Answer 3

Me parece que te está costando bastante conseguir que los artistas usen SVN y presionar DVCS sobre ellos sería una batalla perdida. ¿Quizás hay una forma de actualizar DVCS con checkins SVN para que el DVCS pueda estar actualizado con SVN?

En cuanto a la adopción de SVN, creo que realmente atrapa a las personas que lo ven como algo que necesitan (o no pueden vivir sin él), en lugar de algo que "el hombre" les está forzando a hacer. Si pudieran ver cómo pueden beneficiarse de la herramienta (es decir, volviendo a las revisiones anteriores, etc.), es posible que estén más dispuestos a adoptarla. Sin embargo, no sé si SVN puede beneficiar a un artista como lo hace un programador.

Como programador que ha desarrollado tanto con como sin VCS, honestamente puedo decir que el mundo de VCS es un lugar mucho mejor, y nunca volveré a un mundo sin él.

Answer 4

Con Mercurial, tiene la opción de permitir que los artistas continúen con Subversion, mientras que permite a los desarrolladores cambiar a Mercurial y así disfrutar de los beneficios del control de revisión distribuida.

El truco es usar un Subversion subrepository en Mercurial. Mercurial le permite anidar repositorios: Mercurial 1.7 tiene soporte para los subrepositorios de Mercurial y Subversion, Mercurial 1.8 tendrá soporte para los subrepositorios de Git.

Usted controla un subrepo a través de un archivo llamado .hgsub. En su caso, deberá añadir algo como esto en el fichero:

 
graphics/rendered = [svn]http://svn.example.org/graphics/rendered 

Esto indica a Mercurial para hacer una svn checkout de http://svn.example.org/graphics/rendered y para guardarlos en la caja como graphics/rendered en su copia de trabajo de Mercurial. En otras palabras, el formato del archivo es .hgsub

mount-point = [type]source-URL 

a tomar la primera de pagar usted mismo, añada el archivo .hgsub y hacer una Mercurial cometió. En ese momento, Mercurial tomará nota de la revisión precisa de Subversion que está desprotegida en su subrepo. Este número de revisión se almacena en .hgsubstate, que es un archivo extra rastreado por Mercurial.

Cuando otro desarrollador hace un clon del repositorio Mercurial, Mercurial se dará cuenta de los archivos y .hgsub.hgsubstate, y utilizarlos para recrear la caja de Subversion que cometió.

Las ventajas de esta solución son:

1. los artistas pueden seguir trabajando con la subversión. Aquí estoy simplificando un poco las cosas asumiendo que pueden trabajar con sus archivos gráficos de forma aislada sin clonar el repositorio externo de Mercurial.Incluso si eso no es cierto, aún pueden hacer la mayoría de su trabajo usando Subversion y solo hacer hg pull --update de vez en cuando para obtener los últimos cambios de Mercurial.

2. desarrolladores no tienen que descargar todas las revisiones de todos los archivos de gráficos. Esto es normalmente un stop-show para (cualquiera) sistema de control de revisión distribuido cuando se habla de archivos binarios grandes.

   El problema es que con el control de revisión centralizado, solo el servidor necesita almacenar todas las revisiones de un archivo determinado, pero con el control de revisión distribuida cada desarrollador almacena cada versión.

   La externalización de los activos binarios en un subrepo de Subversion acelera este problema.

Mercurial es todo sobre el control de revisiones y sobre darle instantáneas coherentes del proyecto. Por lo tanto, Mercurial solo revisará las cosas que fueron explícitamente comprometidas. Esto significa que los desarrolladores tendrán que tirar regularmente en nuevas revisiones de Subversion:

$ cd graphics/rendered 
$ svn update 
$ cd ../.. 
$ # test new graphics! 
$ hg commit -m 'Updated graphics' 

El Mercurial cometen está cometiendo el nuevo número de revisión de Subversion en el archivo .hgsubstate - Mercurial se encargará de insertar el número en el archivo, los desarrolladores solo tienen que comprometerlo. De esta forma, cada conjunto de cambios de Mercurial hará referencia a una revisión de Subversion en particular a través del archivo .hgsubstate, y así podrá recrear cualquier estado pasado (que consista en código fuente y gráficos) con precisión.

Answer 5

puede ser que sea un poco tarde a la fiesta (y espero que no fuera de tema), pero en su puesto original que se menciona:

"Tenga en cuenta que el uso de algo así como Perforce, independientemente de la forma adecuada es podría ser para el trabajo, no es la opción para un proyecto de código abierto de forma gratuita. "

si usted está realmente interesado en Perforce que podría estar interesado en saber:

"Si desarrolla software que se licencia o distribuidos exclusivamente bajo una licencia de código abierto de lo contrario, puede haber elegible para obtener una licencia de Perforce sin costo. Esto incluye actualizaciones, pero no incluye Soporte técnico. " - http://www.perforce.com/perforce/price.html

Answer 6

Tenemos artistas trabajando en juegos con GIT. Para nosotros, el cliente SmartGIT es esencial.

También viene en sabor SVN.

Enlace http://www.syntevo.com/smartgit/index.html