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

Question

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

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

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

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

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

Answer 1

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

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

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

Возвращаясь к AppCache, я обнаружил, что самое простое:

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

Я понятия не имею, какой язык вы используете, но в мире 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

Answer 2

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

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

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 -

Answer 3

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

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