Git: обработка appcache?

У меня есть проект OSS для GitHub, в котором есть несколько разных разработчиков. Этот проект представляет собой веб-приложение, которое использует AppCache, чтобы сообщить браузеру, что файлы должны быть доступны в автономном режиме.

Это характер файла appcache, который необходимо обновить (например, мы используем временную метку в комментарии для этого), как только файл в кеше изменяется, чтобы аннулировать кеш и заставить браузер перезагружать все файлы.
Когда люди работают сейчас в разных ветвях развития, они обновляют метку времени в appcache с каждым из своих коммитов.

Проблема заключается в том, что это создаст конфликты, которые предотвращают автоматическое слияние.

  • Как это можно решить так, чтобы в будущем не возникли конфликты?
  • Что другие команды разработчиков делают в одной и той же ситуации?

Используя CVS, я могу заменить метку времени на $Id $, чтобы программа автоматически обрабатывала ее...

ОТВЕТЫ

Ответ 1

У меня большой опыт работы с приложениями с поддержкой AppCache, обслуживаемыми стекю Rails.

Я нашел, что проще всего не переустановить вашу версию в ваш AppCache. Вы должны генерировать файл динамически и программно генерировать уникальное значение для версии. В идеале, никто не должен вводить изменения в сами манифесты, они должны вносить изменения в входы, которые программно генерируют файл.

Это не совсем уникально для AppCache. Если вы обнаружите, что одна конкретная строка должна быть изменена практически во всех фиксациях, вы, вероятно, не должны жестко кодировать эту строку. Он должен быть сгенерирован каким-то образом, основываясь на любых изменениях в запросе репо на изменение этой строки.

Возвращаясь к AppCache, я нашел, что проще всего сделать это:

  • в разработке, укажите время последнего изменения всех файлов в appcache
  • в производстве, включайте идентификатор фиксации развернутого Git commit

Я понятия не имею, какой язык вы используете, но в мире Rails мой манифест AppCache выглядит примерно так: Никому никогда не придется менять этот файл, они будут добавлять или удалять файлы из массива @files, который управляется в контроллере, который обслуживает этот манифест:

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:
*

Первая часть, заключенная в Rails.env.development?, выводит ряд строк комментариев, содержащих последнее модифицированное время каждого файла, включенного в манифест. Это означает, что во время разработки AppCache будет автоматически истек, когда будет изменен любой файл, включенный в него.

В процессе производства AppCache истек, когда был установлен новый коммит. Это может быть излишним для вас; если вы хотите избежать ненужного истечения срока действия AppCache своих пользователей, вы должны сделать что-то более умное, как хеширование задействованных файлов, чтобы срок действия кеша истекал при изменении их содержимого.

В конце концов, я закончил писать небольшую библиотеку, чтобы помочь устранить повторяющиеся биты генерации манифестов. Во избежание использования Rails вам может быть полезно: https://github.com/meagar/rails_appcache

Ответ 2

Используя CVS, я могу заменить метку времени на $Id $, чтобы программа автоматически обрабатывала ее...

git может вызывать git log --format= обработчик для выбранных файлов при экспорте кода для развертывания.

echo \*.meta  export-subst   >>.gitattributes

echo   '$Format:%cD$'   >test.meta   # there lots of % codes available.
git add .; git commit -m-; 

git archive v2.3.6 | tar xCf /dir/that/appcache/is/watching -

Ответ 3

Чтобы эмулировать расширение ключевого слова CVS в обычном кавычке Git, вы можете использовать фильтры очистки/смазывания в Git, как описано здесь: Расширение ключевого слова.

Другой вариант - продолжать делать это так, как вы делаете, но определить настраиваемый драйвер слияния, который удаляет отметки времени перед слиянием, выполняет само слияние, а затем снова добавить новую метку времени.