Come ottenere il set di modifiche del tag dopo aver clonato o estratto un tag usando mercurial?

Question

Come la guida definitiva aptly points out (ricerca di "Tag e la clonazione"):

Quando si esegue hg clone -r foo clonare un repository come di tag foo, il nuovo clone non conterrà alcuna revisione più recente di quella del l'etichetta si riferisce a, inclusa la revisione in cui è stato creato il tag. Il risultato è che avrai esattamente il sottoinsieme giusto della cronologia del progetto nel nuovo repository , ma non è il tag che ti saresti aspettato.

Significa hg tags nel tuo nuovo clone NON mostra il tag foo. La stessa cosa accade se si è clonato prima che sia stato aggiunto il tag foo e si faccia hg pull -r foo.

(Digressione: il tag è l'unica cosa che non riesco a ottenere in hg. Capisco che ci sono dei vantaggi (ad esempio unire) nel metterlo in un changeset, ma è sempre strano avere metadati mescolati con l'origine codice.)

Dovrebbe essere ovvio che sto chiedendo un modo automatico, invece di tirare il changeset del tag come una fase manuale separata.

So che potrei verificare per questo scenario in un hook incoming (quindi funziona sia per clonare sia per tirare), oppure per avvolgere clone e pull.

Ma c'è un modo migliore/più semplice?

---

UPDATE hg bug tracker ha già this issue.

Answer 1

Sì, può essere eseguito da ganci post-clone/pull, ma ci sono un paio di imbroglioni.

Innanzitutto, funziona solo per il repository locale, poiché non è possibile ottenere l'elenco dei tag in un repository remoto.

In secondo luogo, trattare argomenti e opzioni clone/pull non è banale. (Per clone ho bisogno di ottenere il repository di destinazione, -r, -u, -U. Per tirare ho bisogno di -r e -u.) Ho provato a usare fancyopts, ma non può occuparsi di opzioni globali, che vengono elaborate in spedizione. Sono riuscito a modificare il dispatch per darmi solo gli args e le opts di un comando, ma sembra e sembra brutto.

L'utilizzo del wrapper dei comandi eliminerebbe il secondo problema.

Spero che un giorno hg aggiunga un'opzione per clonare e tirare per farlo in modo pulito.

Answer 2

C'è un hook postclone. Si chiama post-clone (la pagina man di hgrc mostra un numero post-ANYCOMMAND e pre-ANYCOMMAND) sebbene, come hai indicato, potresti utilizzare anche gli hook *changegroup o update, poiché clone utilizza entrambe le funzioni (a meno che non si sopprima l'aggiornamento con -U).

Che ne dici di aggiungere un --localtag in modo da avere il nome ma non il set di modifiche aggiuntivo se necessario per riferimento. Qualcosa come

hg clone -r tagname URL 
hg tag --local tagname 

che potresti facilmente costruire in un alias di shell.

Oltre a questo non è necessariamente garantito un modo per avere la revisione X e la revisione in cui la revisione X viene taggata senza avere anche altre revisioni che non si desidera poiché il tag potrebbe essere stato applicato dopo che è stato eseguito altro lavoro. Ovviamente puoi sempre aggiornare a "X" e avere i successivi changeset nella tua directory di lavoro, ma saranno ancora nel tuo repository.

Onestamente, una volta ho capito che il nome del tag non arriva molto tempo quando cloni fino a un tag, che ammetto di aver confuso all'inizio, non ho trovato alcun bisogno di portare con me il changeset con il tag in esso.

Answer 3

Vuoi un attacco gigantesco con bash e uno script Perl incorporato? Bene, eccolo ...

#!/bin/bash 
if [[ "$1" == "" || "$2" == "" || "$3" == "" ]]; then 
    echo 'hgclonetag <src> <tgt> <tag>' 
    exit 1; 
fi 

REV=`hg log -R $1 --rev $3: --limit=2 | perl -F: -lane 'if (/:([\dA-Fa-f]+)$/) {print $F[2] if defined($flag);$flag=1;}'` 
hg clone --rev $REV $1 $2 

Questo richiama il comando hg log per estrarre il numero di revisione dopo la prima revisione tag correlati e quindi cloni a questa revisione.

Attualmente questo non funziona sui repository remoti: lo switch -R funziona solo su repository locali, sfortunatamente.

Answer 4

Più ci penso e più mi sono convinto della destra risposta è quella di clonare proprio tutto e aggiornamento per il tag, che può essere fatto in una sola fase:

hg clone http://host/path#tagname 

che ottiene fai tutto e poi fa hg update in tagname che imposta la tua directory di lavoro sulla revisione corretta. Dato che la compressione delta non è necessariamente molto più grande, e se lo è puoi automatizzare la clonazione del grosso da un precedente clone locale.