Control de versiones para gráficos

Question

Digamos que un equipo de desarrollo incluye (o hace uso de) artistas gráficos que crean todas las imágenes que entran en un producto. Tales cosas incluyen iconos, mapas de bits, fondos de ventanas, imágenes de botones, animaciones, etc.

Obviamente, todo lo que se necesita para construir un software debe estar bajo alguna forma de control de versiones. Pero la mayoría de los sistemas de control de versiones para desarrolladores están diseñados principalmente para información basada en texto. ¿Los gráficos deberían usar el mismo sistema de control de versiones y el repositorio que los codificadores? Si no, ¿qué deberían usar y cuál es la mejor manera de mantener todo sincronizado?

Answer 1

Sí, tener recursos artísticos en el control de versiones es muy útil. Obtiene la capacidad de realizar un seguimiento del historial, deshacer los cambios, y tiene una sola fuente para hacer copias de seguridad. Tenga en cuenta que los recursos artísticos son MUCHO más grandes, por lo que su servidor necesita tener mucho espacio de disco & ancho de banda de red.

He tenido éxito con el uso de perforce en proyectos muy grandes (+100 GB), sin embargo, tuvimos que ajustar el acceso al servidor de control de versiones con algo un poco más amigable para el artista.

También he oído algunas cosas buenas sobre Alienbrain, parece que tiene una interfaz de usuario muy resbaladiza.

Answer 2

Usamos subversion. Simplemente coloque una carpeta en/trunk/docs para composiciones y haga que los diseñadores revisen y se comprometan con esa carpeta. Funciona como un campeón.

Answer 3

Definitivamente pondría los gráficos bajo control de versión. La diferencia puede no ser muy útil desde dentro de una herramienta diff como diffmerge, pero aún puede obtener dos versiones del gráfico y verlas una al lado de la otra para ver las diferencias.

No veo ningún motivo por el que los gráficos resultantes no se deban mantener en el mismo sistema de control de versiones que usan los codificadores. Sin embargo, cuando crea gráficos usando archivos PSD o PDN, puede crear un repositorio separado para ellos, ya que tienen un contexto diferente al jpeg o gif final real que se produce y despliega con la aplicación desarrollada.

Answer 4

@lomaxx TortoiseSVN incluye un programa llamado TortoiseIDiff que parece ser un diff para las imágenes. No lo he usado pero parece intrigante.

Answer 5

Interesante pregunta. No tengo mucha experiencia trabajando directamente con diseñadores en un proyecto. Cuando lo hice, fue a través de un acuerdo contractual donde "entregaron" un diseño. He hecho parte de mi propio trabajo de diseño tanto para sitios web como para aplicaciones de escritorio, y aunque no he usado el control de código fuente en el pasado, estoy en el proceso de implementar SVN para mi propio uso ya que estoy comenzando a trabajar como autónomo remunerado. trabajo. Tengo la intención de utilizar el control de versión/fuente exactamente de la misma manera que lo haría con el código fuente. Simplemente se convierte en otra carpeta en el tronco del proyecto. La forma en que he trabajado sin control de código fuente es crear una carpeta de assets en la cual residen todos los archivos de medios que son equivalentes del código fuente. Me gusta pensar en Photoshop PSD como código fuente de gráficos mientras que la salida JPEG para un sitio web o de lo contrario es la versión compilada.

En el caso de trabajar con diseñadores, lo cual es una posibilidad clara que enfrentaré en un futuro próximo, me gustaría hacer un intento para que ellos "controlen" sus diferentes versiones de sus archivos fuente de forma regular base. Tendré curiosidad por leer lo que otros con alguna experiencia dirán en respuesta a esto.

Answer 6

Con respecto a la diferencia y la fusión, creo que el control de la versión es más crítico para los elementos de gráficos y medios. Si lo piensas bien, la mayoría de los diseñadores serán los únicos propietarios de un archivo, al menos en el caso de los gráficos, o al menos yo diría que ese sería el caso. Me gustaría saber de un diseñador.

Answer 7

Nosotros, también, solo ponemos los binarios en control de fuente. Usamos Git, pero se aplicaría igual de bien a Subversion.

Una sugerencia que tengo es usar SVG siempre que sea posible, ya que puede ver las diferencias reales. Con los binarios (la mayoría de los demás formatos de imagen), lo mejor que puede obtener es un historial de versiones.

Answer 8

Muchos de los tipos de gráficos querrán algo más sofisticado que la subversión.Si bien es bueno para el control de versiones, querrán un sistema de administración de contenido que permita la referencia cruzada de activos, etiquetado, miniaturas y ese tipo de cosas (además del control de versiones).

Answer 9

@Damian - Buen punto sobre el etiquetado y la referencia cruzada. Es verdad; aunque no he trabajado con muchos diseñadores en un proyecto de desarrollo de software, he trabajado para una empresa que tenía un departamento de diseño y sé que esto es un problema. Los diseñadores siguen (perpetuamente) buscando el sistema perfecto para manejar este tipo de cosas. Creo que esto es más adecuado para un departamento de diseño para acceso compartido, búsqueda y control de versiones, etc. a todos los activos, donde existe un incentivo comercial para no reinventar la rueda donde sea y siempre que sea posible. No creo que se aplique para una manera orientada a proyectos ya que el etiquetado y la referencia cruzada no serían tan aplicables.

Answer 10

Mantenemos los archivos binarios y las imágenes en control de revisión, usando Perforce. ¡Es genial!

Mantenemos una gran cantidad de recursos artísticos, y se adapta bien a una gran cantidad de archivos de gran tamaño. Reconoce los archivos binarios, los que no se pueden diferir, y los almacena como copias completas de archivos en el back-end.

Tiene P4V (navegador visual multiplataforma) y un sistema de miniaturas para que los archivos de imagen se puedan ver en el navegador.

Answer 11

TortoiseSVN puede mostrar las revisiones de las imágenes una al lado de la otra, lo que es realmente útil. Lo he usado con diferentes equipos con un gran éxito. A los artistas les encantaba tener la capacidad de hacer retroceder las cosas (después de que se acostumbraron a los conceptos). Sin embargo, toma mucho espacio.

Answer 12

Es posible que desee echar un vistazo a Boar: "Control de versión simple y copia de seguridad para fotos, videos y otros archivos binarios". Puede manejar archivos binarios de cualquier tamaño. http://code.google.com/p/boar/

Answer 13

GitHub recientemente presentó "modos de vista de imagen", eche un vistazo: https://github.com/blog/817-behold-image-view-modes.

Answer 14

Una solución gratuita y algo endeble es Adobe version Cue viene con Adobe Suites hasta CS4 y es fácil de instalar y mantener. Ofrece control de nivel de usuario y es amigable para el artista. Adobe suspendió el soporte, lo que es una pena. Adobe Bridge actúa como el cliente entre el usuario y el servidor Version Cue. Si se usa adecuadamente, es una solución económica para el control de versiones. Yo uso cue de versión CS3 con CS3 Bridge. Funciona muy bien para equipos pequeños.

Answer 15

En mi opinión Pixelapse combinado con una solución de respaldo es el mejor software de control de versiones para gráficos que he encontrado hasta ahora. Admite archivos adobe y un montón de imágenes ráster normales. Tiene versión por vista previa de la versión. Se guarda automáticamente cuando los archivos se actualizan (al guardar). Funciona como Dropbox pero tiene una excelente interfaz web.

Puede usarlo en equipos y compartir proyectos para diferentes personas. También admite revisores infinitos, lo cual es ideal para agencias de diseño. Y si lo desea, puede colaborar públicamente en proyectos que están "abiertos".

Lamentablemente no se puede tener un servidor pixelap local, por lo que para la copia de seguridad mi configuración actual es que tengo la carpeta Pixelapse (como una carpeta de Dropbox) dentro de un git repo para la creación de instantáneas.