¿Cómo administro apropiadamente los activos de arte grandes en DVCS?

¿Hay alguna manera de manejar grandes activos (es decir, miles de imágenes, películas flash, etc.) con una herramienta DVCS como hg y git ? Tal como lo veo, clonar repositorys llenos con activos de 4 GB parece una sobrecarga innecesaria ya que se revisarán los files. Parece bastante engorroso si tiene un código fuente mezclado con files de activos.

¿Alguien tiene alguna idea o experiencia al hacer esto en un context de desarrollo web?

Estos son algunos pensamientos que he tenido sobre este asunto del tema. Al final, es posible que deba mantener los activos y el código lo más separados posible. Puedo pensar en varias estrategias posibles:

Distribuido, dos repositorys

Activos en un repo y código en el otro.

Ventajas

  • En el context del desarrollo web, no necesitará clonar el repository de activos gigantes si no está trabajando directamente con los files charts. Esto es posible si tiene un server web que maneja activos separados del contenido dynamic (PHP, ASP.NET, RoR, etc.) y se está sincronizando con el repository de activos.

Desventajas

  • Las herramientas DVCS no hacen un seguimiento de otros repositorys aparte del suyo, por lo que no hay soporte directo de list de materiales (list de materiales), es decir, no hay una forma clara de saber cuándo ambos repositorys están sincronizados. (Supongo que para eso es git-submodule o repo ).

    Ejemplo: el artista agrega una nueva image en un repository y el progtwigdor agrega una function para usar la image; sin embargo, cuando alguien tiene que retroceder en las versiones, se ve obligado a realizar un seguimiento de estos cambios por sí mismo.

  • Sobrecarga del repository de activos a pesar de que solo afecta a quienes lo usan.

Distribuido, un repository

Los activos y el código residen en el mismo repository pero están en dos directorys separados.

Ventajas

  • El control de versiones del código y los activos están entrelazados, por lo que la list de materiales es práctica. Retroceder es posible sin muchos problemas.

Desventajas

  • Como las herramientas de control de versiones distribuidas realizan un seguimiento de la estructura completa del proyecto, por lo general no hay forma de consultar un solo directory.
  • Aún tienes el problema con la sobrecarga del repository. Aún más, necesita verificar los activos y el código.

Ambas estrategias enumeradas anteriormente todavía tienen la desventaja de tener una gran sobrecarga, ya que es necesario clonar el repository de activos de gran tamaño. Una solución a este problema es una variante de la primera estrategia anterior, dos repositorys; mantenga el código en el repository de VCS distribuido y los activos en un repository de VCS centralizado (como SVN, Alienbrain, etc.).

Teniendo en count cómo la mayoría de los diseñadores charts trabajan con files binarys, generalmente no es necesario ramificarse a less que sea realmente necesario (nuevas funciones que requieren muchos activos que no son necesarios hasta mucho más tarde). La desventaja es que deberá encontrar una forma de hacer una copy de security del repository central. De ahí una tercera estrategia:

Activos fuera del repository (o Activos en CMS en su lugar)

Código en el repository como siempre y los activos no están en el repository. Los activos deberían colocarse en algún tipo de sistema de administración de contenidos / medios / activos en su lugar o al less en una carpeta que regularmente se respalde. Esto supone que hay muy poca necesidad de retroceder en las versiones con charts. Si hay una necesidad de back-tracking, los cambios charts son insignificantes.

Ventajas

  • No hincha el repository de código (útil para, por ejemplo, git, ya que con frecuencia hace la comprobación de files)
  • Permite un manejo flexible de los activos, como la implementación de activos en serveres dedicados a activos simples
  • Si está en CMS con una API, los activos deberían ser relativamente fáciles de manejar en el código

Desventajas

  • Sin soporte de BOM
  • No es fácil la compatibilidad con el respaldo de versiones extensas, esto depende de la estrategia de respaldo para sus activos

Pensamientos, sin experiencia: de hecho, separaría el código de los datos. Suponiendo que hay un set de imágenes que pertenece a la aplicación, solo lo mantendría en un server centralizado. En el código, organizaría (mediante encoding explícita) que la aplicación puede integrar activos locales o remotos. Las personas que contribuyen pueden poner nuevas imágenes en su tienda local al principio, integrándolas con algún tipo de procedimiento de carga (explícito) en la tienda central cuando sea necesario y aprobado.

He luchado con esto yo mismo. Como dijiste, versionar GB de activos puede ser un gran dolor.

Para proyectos que requieren participación externa, he encontrado que Mercurial es una solución funcional , pero no excelente. Se come espacio en los discos para files grandes y puede ser bastante lento dependiendo de las circunstancias.

Para mi trabajo de layout interno, prefiero usar herramientas simples de synchronization (rsync, synctoy, lo que sea) para mantener los directorys actualizados entre serveres / máquinas y luego hacer el control de la versión de forma manual. Encuentro que rara vez necesito el control de versiones para nada más allá de revisiones importantes.