Git: gestire un appcache?

Question

Sto ospitando un progetto OSS su GitHub con diversi sviluppatori. Questo progetto è un'applicazione web che sta utilizzando AppCache per dire al browser quali file devono essere resi disponibili offline.

È la natura del file appcache che deve essere aggiornato (ad esempio, stiamo utilizzando un timestamp in un commento per questo) una volta che un file nella cache sta cambiando per invalidare la cache e per forzare il browser a ricaricare tutto File.
Quando le persone stanno lavorando su diversi rami di sviluppo, aggiornano il timestamp nell'appcache con ciascuno dei loro commit.

Il problema ora è che questo creerà conflitti che impediscono un'unione automatica.

• Come può essere risolto in un modo che i conflitti non si ripetano in futuro?
• Cosa stanno facendo altri team di sviluppo nella stessa situazione?

Utilizzando CVS ho potuto sostituire il timestamp con un $ Id $ per lasciare che il programma di gestirlo automaticamente ...

Answer 1

Ho un grande corpo di esperienza di lavoro con le applicazioni AppCache sostenuti serviti da una pila Rails .

Ho trovato che la cosa più semplice è di non hardcode la tua versione in AppCache. Dovresti generare il file in modo dinamico e generare in modo programmatico un valore univoco per la versione. Idealmente, nessuno dovrebbe introdurre modifiche agli stessi manifest, dovrebbero introdurre modifiche agli input che generano il file in modo programmatico.

Questo non è univoco per l'AppCache. Se trovi la necessità di modificare una riga specifica praticamente in ogni commit, probabilmente non dovresti codificare quella linea. Dovrebbe essere generato in qualche modo, in base a qualsiasi cambiamento nel repository richiedere una modifica a quella linea.

Tornando alla AppCache, ho trovato la cosa più facile da fare è:

• in fase di sviluppo, includono l'dell'ultima modifica di tutti i file nella AppCache
• in produzione, includere il commit ID del commit Git distribuito

Non ho idea di quale lingua si sta utilizzando, ma nel mondo Rails, il mio manifest AppCache è stato simile al seguente. Nessuno avrebbe mai dovuto cambiare questo file, avrebbero solo aggiungere o rimuovere file dal @files matrice, che è gestito nel controller che serve questo manifesto:

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 prima parte, avvolto in Rails.env.development? emette una serie di righe di commento, contenente l'ora dell'ultima modifica di ogni file incluso nel manifest. Ciò significa che, durante lo sviluppo, l'AppCache verrà automaticamente scaduto ogni volta che qualsiasi file incluso in esso viene modificato.

In produzione, AppCache è scaduto quando è stato distribuito un nuovo commit. Questo potrebbe essere eccessivo per te; se vuoi evitare di dover scartare inutilmente AppCache dai tuoi utenti, dovresti fare qualcosa di più intelligente come eseguire un hash dei file in modo che la cache scada quando i loro contenuti cambiano.

Alla fine, ho finito per scrivere una piccola libreria per aiutare ad eliminare i bit ripetitivi di generare manifesti. Sulla remota possibilità che si sta utilizzando Rails, si potrebbe trovare utile: https://github.com/meagar/rails_appcache

Answer 2

Utilizzando CVS ho potuto sostituire il timestamp con un $ Id $ per lasciare che il programma di gestirlo automaticamente ...

git può chiamare git log's --format= handler sui file selezionati quando esporti il ​​codice per la distribuzione.

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

di emulare l'espansione CVS parola chiave in una pianura cassa Git, è possibile utilizzare i filtri puliti/sbavature in Git, come spiegato qui: Keyword Expansion.

Un'altra opzione è continuare a farlo come si fa, ma lo define a custom merge driver rimuove i timestamp prima dell'unione, esegue l'unione stessa e quindi aggiunge nuovamente un nuovo timestamp.