usar - ¿qué tipo de sistema control de versiones es git?

¿Pueden los artistas lidiar de forma realista con el control de versiones(distribuidas) en un entorno de código abierto? (6)

Heya, estoy trabajando en el departamento de administració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. Las versiones de origen de los activos (modelos, texturas) residen en una rama de medios separada, mientras que las versiones representadas de los activos (estamos trabajando en un juego 2D isométrico, así que usamos imágenes renderizadas 2d de los modelos 3D en el juego) 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 consiste principalmente en programadores y estamos considerando pasar de SVN a control de versiones distribuidas para facilitar el trabajo con las sucursales (y el proceso de fusión asociado) y enviar 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ía menos inteligente.

Así que estoy buscando todo tipo de consejos sobre cómo podemos facilitar el flujo de trabajo de control de versiones para artistas. Tenga en cuenta que usar algo como Perforce, independientemente de lo adecuado que sea para el trabajo, no es una opción para un proyecto de código abierto gratuito. Así que estoy buscando consejos, tutoriales, herramientas de proyectos que faciliten a los artistas el control de versiones distribuidas, especialmente Hg y / o Git.

¿Vale la pena recorrer esa ruta e intentar que los artistas utilicen el control de versiones distribuidas? 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, por ejemplo, el tutorial de Hginit . 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 utilizamos Trac para fines de gestión de proyectos, así que si conoce un plugin de Trac que sea amigable con el artista, hágamelo saber también :-)

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 subrepositorio de Subversion 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 tu caso, deberías agregar algo como esto al archivo:

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

Esto le indica a Mercurial que haga una svn checkout de svn checkout de http://svn.example.org/graphics/rendered y que guarde el pago como graphics/rendered en su copia de trabajo de Mercurial. En otras palabras, el formato del archivo .hgsub es

mount-point = [type]source-URL

.hgsub la primera comprobación usted mismo, agregue el archivo .hgsub y realice una confirmación de Mercurial. 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 haga un clon del repositorio de Mercurial, Mercurial verá los archivos .hgsub y .hgsubstate , y los usará para recrear el pago de Subversion que haya realizado.

Las ventajas de esta solución son:

los artistas pueden continuar trabajando con Subversion. Aquí estoy simplificando un poco las cosas al asumir que pueden trabajar con sus archivos gráficos de forma aislada sin clonar el repositorio externo de Mercurial. Incluso si eso no es cierto, entonces aún pueden hacer la mayoría de su trabajo usando Subversion y solo hacer hg pull --update vez en cuando para obtener los últimos cambios de Mercurial.
los desarrolladores no tendrán que descargar todas las revisiones de todos los archivos gráficos. Esto es normalmente un show-stopper para (cualquier) 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 dado, 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 tiene que ver con el control de revisiones y con proporcionar 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 recurrir regularmente a nuevas revisiones de Subversion:

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

El compromiso de Mercurial está comprometiendo 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 confirmarlo. De esta forma, cada conjunto de cambios Mercurial hará referencia a una revisión particular de Subversion 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.

Los siguientes son una buena introducción visual al control de versiones y Mercurial.

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

Así que aquí hay algunas buenas presentaciones visuales:

Git expone un modelo más detallado, que gusta a 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.

Me parece que te está costando mucho 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 obliga 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.

Ni siquiera estoy seguro de que los programadores puedan lidiar de forma realista con el control de versiones distribuidas. Como prueba, ofrezco la cantidad de preguntas sobre control de versiones distribuidas en .

Mi sugerencia sería darles 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 la fuente, uno de los programadores puede explicar los detalles.

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

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

podría llegar un poco tarde a la fiesta (y con suerte no fuera del tema), pero en tu publicación original mencionaste:

"Tenga en cuenta que usar algo como Perforce, independientemente de lo adecuado que sea para el trabajo, no es una opción para un proyecto de código abierto gratuito".

Si está realmente interesado en Perforce, le puede interesar saber:

"Si desarrolla software que tiene licencia o se distribuye de manera exclusiva bajo una licencia de código abierto, puede ser elegible para obtener una licencia de Perforce sin cargo. Esto incluye actualizaciones, pero no incluye soporte técnico". - http://www.perforce.com/perforce/price.html