Git: ¿manejando una aplicación?

Estoy organizando un proyecto de OSS en GitHub que tiene algunos desarrolladores diferentes. Este proyecto es una aplicación web que usa una AppCache para indicar al browser qué files deben estar disponibles sin connection.

Es la naturaleza del file de aplicación que necesita ser actualizado (por ejemplo, estamos usando una timestamp en un comentario para eso) una vez que un file en la memory caching está cambiando para invalidar la memory caching y obligar al browser a volver a cargar todos los files.
Cuando las personas trabajan ahora en diferentes twigs de desarrollo, están actualizando la timestamp en la aplicación con cada una de sus confirmaciones.

El problema ahora es que esto creará conflictos que impiden una fusión automática.

  • ¿Cómo se puede resolver esto de manera que no vuelva a haber conflictos en el futuro?
  • ¿Qué están haciendo otros equipos de desarrollo en la misma situación?

Usando CVS podría replace la timestamp con $ Id $ para que el progtwig la maneje automáticamente …

Tengo un gran cuerpo de experiencia trabajando con aplicaciones respaldadas por AppCache servidas por una stack de Rails.

Descubrí que lo más fácil es no codificar tu versión en tu AppCache. Debe generar el file dinámicamente y generar programáticamente un valor único para la versión. Idealmente, nadie debería introducir cambios en los manifiestos, deberían introducir cambios en las inputs que generan programáticamente el file.

Esto no es realmente exclusivo de AppCache. Si encuentra que una línea específica necesita ser modificada en prácticamente cada confirmación, probablemente no sea difícil codificar esa línea. Debería generarse de alguna forma, en function de los cambios en el repository que indiquen un cambio en esa línea.

Volviendo a AppCache, he encontrado que lo más fácil es:

  • en desarrollo, incluya la hora de última modificación de todos los files en la aplicación
  • en producción, incluya el ID de confirmación del compromiso de Git implementado

No tengo idea de qué idioma estás usando, pero en el mundo de Rails, mi manifiesto de AppCache se parecía más o less al siguiente. Nadie tendría que cambiar este file, solo agregarían o eliminarían files de la matriz @files , que se administra en el controller que sirve este manifiesto:

 CACHE MANIFEST <% if Rails.env.development? %> <% @cached_files.each do |file| %> # <%= File.mtime(file) %> <% end %> <% else %> # <%= `git rev-parse HEAD` %> <% end %> CACHE: <% @cached_files.each do |file| %> <%= file %> <% end %> NETWORK: * 

La primera parte, envuelta en Rails.env.development? genera una serie de líneas de comentarios, que contienen la hora de última modificación de cada file incluido en el manifiesto. Esto significa que, durante el desarrollo , AppCache caducará automáticamente cada vez que se modifique cualquier file incluido en él.

En producción, AppCache expiró cuando se implementó una nueva confirmación. Esto podría ser excesivo para ti; Si desea evitar que caduque innecesariamente la aplicación de sus usuarios, debe hacer algo más inteligente como copyr los files involucrados para que la memory caduque cuando cambien sus contenidos.

Al final, terminé escribiendo una pequeña biblioteca para ayudar a eliminar los fragments repetitivos de manifiestos generadores. Si está utilizando Rails, es posible que le resulte útil: https://github.com/meagar/rails_appcache

Usando CVS podría replace la timestamp con $ Id $ para que el progtwig la maneje automáticamente …

git puede llamar a git log 's --format= handler en los files seleccionados cuando está exportando código para la implementación.

 echo \*.meta export-subst >>.gitattributes echo '$Format:%cD$' >test.meta # there's lots of % codes available. git add .; git commit -m-; git archive v2.3.6 | tar xCf /dir/that/appcache/is/watching - 

Para emular la expansión de palabras key de CVS en un process de pago simple de Git, puede usar filters de limpieza / borrado en Git, como se explica aquí: Expansión de palabras key .

Otra opción es continuar haciéndolo de la forma en que lo hace, pero defina un controller de combinación personalizado que elimine las marcas de time antes de la fusión, realice la fusión por sí mismo y luego vuelva a agregar una nueva timestamp.