2015-04-26 9 views
15

Jestem gospodarzem projektu OSS na GitHub, który ma kilku różnych programistów. Ten projekt jest aplikacją internetową, która używa AppCache do informowania przeglądarki, które pliki powinny być dostępne w trybie offline.Git: obsługa appcache?

To jest charakter pliku appcache, który należy zaktualizować (np. Używamy znacznika czasu w komentarzu do tego), gdy plik w pamięci podręcznej zmienia się, aby unieważnić pamięć podręczną i zmusić przeglądarkę do ponownego załadowania wszystkich akta.
Kiedy ludzie pracują teraz w różnych gałęziach rozwoju, aktualizują znacznik czasu w appcache z każdym z ich zatwierdzeń.

Problem polega na tym, że spowoduje to konflikty, które uniemożliwiają automatyczne scalanie.

  • Jak można to rozwiązać w sposób, który nie spowoduje konfliktów w przyszłości?
  • Co robią inne zespoły programistów w tej samej sytuacji?

Korzystanie z CVS mógłbym wymienić znacznik czasu z $ ID $, aby program automatycznie go obsługiwać ...

+0

Pytanie jest ogólne i powinno być również ogólne. Ale dla informacji: w moim przypadku aplikacja używa tylko statycznych plików JavaScript, CSS i HTML, więc wystarczy bardzo prosty serwer WWW. Niektóre opcjonalne części używają PHP - ale nie jest to trudne wymaganie dla środowiska wykonawczego (ale domyślam się, że 100% dostępnych serwerów programistycznych go posiada). Jeśli istnieje rozwiązanie, w którym Git powinien wywoływać skrypt, należy wziąć pod uwagę, że programiści używają systemów Linux, Windows i MacOS. – Chris

Odpowiedz

7

Mam duże ciało doświadczenia w pracy z pamięć podręczną aplikacji wspieranych aplikacji obsługiwanych przez stos Rails .

Znalazłem najłatwiejszą rzecz zdecydowanie jest nie hardcode swoją wersję do AppCache. Powinieneś generować plik dynamicznie i programowo generować unikalną wartość dla wersji. Najlepiej byłoby, gdyby nikt nie wprowadzał zmian w samych manifestach, powinny one wprowadzać zmiany w danych wejściowych, które programowo generują plik.

To naprawdę nie jest unikalne dla AppCache. Jeśli zauważysz, że jedna konkretna linia musi zostać zmodyfikowana praktycznie przy każdym zatwierdzeniu, prawdopodobnie nie powinieneś sztywno kodować tej linii. Powinien być generowany w jakiś sposób, w oparciu o wszelkie zmiany w repo, zachęcam do zmiany tej linii.

Wracając do pamięć podręczną aplikacji, Znalazłem najłatwiejszą rzeczą do zrobienia jest:

  • w rozwoju, obejmuje czas ostatniej modyfikacji wszystkich plików w pamięć podręczną aplikacji
  • w produkcji, obejmują commit ID wdrożonego atrybutu Git

Nie mam pojęcia, jakiego języka używasz, ale w świecie Rails mój manifest AppCache wyglądał jak poniżej. Nikt nigdy nie trzeba zmieniać tego pliku, to oni tylko dodać lub usunąć pliki z tablicy @files, który jest zarządzany w kontrolerze, który służy tę manifeście:

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

części pierwszej, owinięte w Rails.env.development? wyprowadza serię linii komentarza, zawierającej czas ostatniej modyfikacji każdego pliku zawartego w manifeście. Oznacza to, że podczas programowania, AppCache będzie automatycznie wygasał, gdy tylko którykolwiek z plików zawartych w nim zostanie zmodyfikowany.

Podczas produkcji AppCache wygasł po wdrożeniu nowego zatwierdzenia. To może być dla ciebie przesada; jeśli chcesz uniknąć niepotrzebnego wygaśnięcia AppCache swoich użytkowników, powinieneś zrobić coś bardziej sprytnego, jak mieszanie odpowiednich plików, aby pamięć podręczna wygasała po zmianie ich zawartości.

W końcu skończyłem pisać małą bibliotekę, aby pomóc wyeliminować powtarzające się fragmenty manifestów generujących. Na off szansa używasz szyny, może okazać się pomocne: https://github.com/meagar/rails_appcache

1

Korzystanie z CVS mógłbym wymienić znacznik czasu z $ ID $, aby program automatycznie go obsługiwać ...

git może wywoływać git log's --format= handler dla wybranych plików podczas eksportowania kodu do wdrożenia.

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 - 
1

naśladować ekspansja CVS słowo w zwykły Git kasie, można użyć filtrów czysty/rozmazywanie w Git, jak wyjaśniono tutaj: Keyword Expansion.

Inną opcją jest kontynuowanie robienia tego tak, jak to robisz, ale define a custom merge driver, które usunie znaczniki czasu przed scaleniem, wykonaj samo scalenie, a następnie ponownie dodaj nowy znacznik czasu.