version-control - usados - ¿cuáles son los tipos de sistema control de versiones?
Control de versión para gráficos (15)
@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 un proyecto orientado, ya que el etiquetado y la referencia cruzada no serían tan aplicables.
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 ventana, imágenes de botones, animaciones, etc.
Obviamente, todo lo que se necesita para construir una pieza de 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?
@lomaxx TortoiseSVN incluye un programa llamado TortoiseIDiff que parece ser un diff para imágenes. No lo he usado pero parece intrigante.
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.
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 cual los gráficos resultantes no se mantengan 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.
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 de 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.
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/
GitHub introdujo recientemente "modos de vista de imagen", eche un vistazo: https://github.com/blog/817-behold-image-view-modes .
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 activos en la que residen todos los archivos de medios que son equivalentes del código fuente. Me gusta pensar en PSD de Photoshop 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 distinta que enfrentaré en el futuro cercano, me gustaría hacer un intento para que ellos "controlen" sus diferentes versiones de sus archivos fuente de forma regular. Tendré curiosidad por leer lo que otros con alguna experiencia dirán en respuesta a esto.
Mantenemos los archivos binarios y las imágenes en control de revisión, usando Perforce. ¡Es genial!
Conservamos muchos recursos artísticos, y se adapta bien a muchos archivos grandes. 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.
Muchos de los usuarios 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).
Nosotros también, simplemente 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, porque puedes 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.
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 y ancho de banda de red.
Tuve éxito con el uso forzado 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 escuchado algunas cosas buenas sobre Alienbrain , pero parece tener una interfaz de usuario muy elegante.
TortoiseSVN puede mostrar revisiones de imagen 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.
Una solución gratuita y ligeramente inestable es Adobe versión 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.
Usamos subversión. 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.