2009-09-30 12 views
7

Nuestro producto es similar a un juego, y es muy rico (~ 40M - 100M) en archivos de soporte binarios - texturas, mallas, películas, etc. Like kai1968, me gustaría poder sincronizar estos recursos, y no solo código, con un solo clic.¿Debo conservar los activos binarios en TFS? ¿Cómo?

Estrictamente hablando, sin embargo, eso es diferente al control de la versión: no deseo cargar nuestro TFS con el historial irrelevante de estos archivos. ¿Puedo de alguna manera cargar cosas sin guardar el historial a TFS? Sería aún mejor si pudiera optar por mantener la historia en puntos específicos (por ejemplo, puntos de etiqueta), y no en cada registro.

En términos más generales, ¿cómo se gestiona la sincronización de los activos binarios?

(soy consciente de other tools, quizás más adecuado para este tipo de tareas, pero divergentes - o por completo la migración - TFS no es una opción en este momento.)

Respuesta

5

Siempre hemos mantenido activos binarios en TFS cuando tenemos que hacerlo, y simplemente nos ocupamos de los efectos colaterales de esa elección (almacenamiento extra, registros más largos porque no se pueden diferir en los binarios, etc.). No creo que haya una manera de destruir selectivamente el historial de ciertos archivos, excepto manualmente. Si quieres hacer esto periódicamente, con la mano, se puede hacer lo siguiente:

  1. obtener una copia curent de los archivos binarios
  2. Destruir (eliminar con historia) las copias binarios en TFS
  3. añadir manualmente los archivos vuelven a TFS

Tendría solo la copia más reciente, pero esto tiene un efecto secundario: rompería cualquier compilación anterior, ya que un intento de recuperar el historial de origen no devolvería estos nuevos copias de los archivos. TFS buscaría una copia que coincida con el proceso de pago que está intentando realizar, y al no encontrar ninguna, no recuperaría una copia de esos archivos. Debería actualizar sus scripts de compilación para extraer los binarios más recientes, así como el código histórico, si desea construir una versión anterior, pero incluso así, no será un historial real.

La segunda opción es solo consultarlos periódicamente, no con cada cambio menor. Por ejemplo, mantenga estos archivos en un lugar seguro (un archivo compartido con copias de seguridad diarias), y luego solo revise los binarios cambiados cada semana más o menos, o antes de cada etiqueta, o lo que sea, de esta manera, no tiene historial incremental, pero aún tendrías el historial de tu etiqueta. Incluso podría considerar escribir algún tipo de rutina automatizada para aplicar etiquetas, donde primero verificará los cambios en esa carpeta y luego aplicará la etiqueta.

Por favor, publique de nuevo lo que termina haciendo - ¡Tengo curiosidad por saber!

+0

Me temo que la respuesta podría ser que ... Una solución que no es un solo clic en el check-in/get-latest se perderá el propósito. Seguiremos sincronizando activos binarios por separado, a través de un recurso compartido de red. ¡Gracias! –

+0

Di esta respuesta con un +1 anterior y todavía no veo el problema. ¿En qué se diferencia de "un clic para registrarse/obtener la última?" Solo tiene que ejecutar el script Destroy de vez en cuando, cuando se queda sin espacio en disco. –

+0

Parece que 2005 no es compatible con "Destruir" - se agregó en 2008, al cual no tengo acceso, por lo que alguien más tendrá que probar esto y completarlo, pero mi sospecha es que "Destruir" rompería una construir. Si hiciste una etiqueta, luego destruiste un archivo que formaba parte de esa etiqueta, luego registraste otro archivo con el mismo nombre, luego intenté OBTENER la etiqueta, no estoy seguro de qué pasaría, tal vez TFS obtenga el archivo más reciente, tal vez recibe la etiqueta sin el archivo destruido, tal vez dice "No se puede obtener la etiqueta". En cualquier caso, no puede reproducir el conjunto exactamente como lo etiquetó, ya que el archivo se ha ido. – SqlRyan

4

Aquí están algunas ideas:

  • considerar el uso de un proyecto VSTS separada, por lo que no se mezclen los binarios y el código en el mismo proyecto. Esto lo hace un poco más fácil de administrar (por ejemplo, puede mantener los activos por separado, y también cualquier elemento de trabajo relacionado con ellos se puede consultar más fácilmente filtrando en el proyecto). En el lado negativo, esto significaría 2 clics para obtener lo último.

  • ¿Por qué no quieres guardar historiales? El punto de control de la fuente es mantener el historial para que pueda volver a una compilación particular para un día en particular. De lo contrario, también podría utilizar un programa de copia de seguridad en una unidad de red (¡y realmente no quiere hacer eso!)

  • Si sólo estás preocupado por el uso de espacio en disco, entonces no. 100MB es pequeño, y los discos duros son baratos. Mi último proyecto de juego tenía cientos de gigabytes de activos y mantuvimos el historial de cada cambio durante más de 3 años.

  • Los activos no ralentizar nada en el estómago. Solo toman tiempo procesar si los registra o los obtiene, que son actividades que deberá realizar incluso si no utiliza el control de código fuente. De hecho, el control de fuente hace las cosas más rápido porque tiene una solución de "un clic lo hace todo".

  • Los muchos otros beneficios de control de código fuente son realmente útiles de los activos, y superan con creces los negativos.

+0

Buenos puntos. Tu realmente me convenciste Trataré de venderlo en el trabajo. –

Cuestiones relacionadas