Mercurial - torna alla vecchia versione e continua da lì

Sto usando Mercurial localmente per un progetto (è l'unico repository che non è possibile spingere / tirare verso / da qualsiasi altra parte).

Ad oggi ha una storia lineare. Tuttavia, la cosa su cui sto lavorando ora ho capito che è un approccio terribile e voglio tornare alla versione prima di avviarla e implementarla in un modo diverso.

Sono un po 'confuso con il branch/ revert/update -C comandi in Mercurial. Fondamentalmente voglio tornare alla versione 38 (attualmente su 45) e avere i miei prossimi impegni con 38 come genitore e andare avanti da lì. Non mi importa se le revisioni 39-45 sono perse per sempre o finiscono in un ramo senza uscita.

Quale comando / set di comandi ho bisogno?

hg update [-r REV]

Se in seguito ti impegni, creerai efficacemente una nuova filiale. Quindi potresti continuare a lavorare solo su questo ramo o eventualmente unire quello esistente in esso.

Ecco il cheat sheet sui comandi:

• hg updatecambia la revisione principale della copia di lavoro e cambia anche il contenuto del file in modo che corrisponda a questa nuova revisione principale. Ciò significa che i nuovi commit continueranno dalla revisione a cui si aggiorna.

• hg revertmodifica solo il contenuto del file e lascia sola la revisione padre della copia di lavoro. In genere si utilizza hg revertquando si decide che non si desidera mantenere le modifiche non impegnate apportate a un file nella copia di lavoro.

• hg branchavvia un nuovo ramo denominato. Pensa a un ramo denominato come un'etichetta che assegni ai changeset. Quindi, se lo fai hg branch red, allora i seguenti changeset saranno contrassegnati come appartenenti al ramo "rosso". Questo può essere un buon modo per organizzare i changeset, specialmente quando persone diverse lavorano su rami diversi e in seguito vuoi vedere da dove proviene il changeset. Ma non vuoi usarlo nella tua situazione.

Se usi hg update --rev 38, allora i changeset 39–45 rimarranno come un vicolo cieco - una testa penzolante come la chiamiamo. Riceverai un avviso quando spingi poiché creerai "più teste" nel repository a cui spingi. L'avvertimento è lì perché è un po 'scortese lasciare tali teste in giro poiché suggeriscono che qualcuno deve fare una fusione. Ma nel tuo caso puoi solo andare avanti e hg push --forcepoiché vuoi davvero lasciarlo sospeso.

Se non hai ancora spinto la revisione 39-45 da qualche altra parte, puoi tenerli privati. È molto semplice: con hg clone --rev 38 foo foo-38te otterrai un nuovo clone locale che contiene solo fino alla revisione 38. Puoi continuare a lavorare foo-38e inviare i nuovi (buoni) cambiamenti che crei. Avrai ancora le vecchie (cattive) revisioni nel tuo fooclone. (Siete liberi di rinominare i cloni tuttavia si desidera, ad esempio, fooa foo-bade foo-38a foo.)

Infine, puoi anche utilizzare hg revert --all --rev 38e quindi eseguire il commit. Ciò creerà una revisione 46 che sembra identica alla revisione 38. Continuerai quindi a lavorare dalla revisione 46. Questo non creerà un fork nella storia nello stesso modo esplicito di prima hg update, ma d'altra parte non ti lamenterai di avere teste multiple. Userei hg revertse collaborassi con altri che hanno già realizzato il proprio lavoro sulla base della revisione 45. Altrimenti, hg updateè più esplicito.

Ho appena riscontrato il caso di dover ripristinare solo un file alla revisione precedente, subito dopo aver eseguito il commit e il push. La sintassi abbreviata per specificare queste revisioni non è coperta dalle altre risposte, quindi ecco il comando per farlo

hg revert path/to/file -r-2

Questo -2tornerà alla versione precedente all'ultimo commit, usando -1si ripristinerebbero solo le attuali modifiche non confermate.

IMHO, si hg strip -r 39adatta meglio a questo caso.

Richiede che l'estensione di mq sia abilitata e abbia le stesse limitazioni del "metodo di repo di clonazione" raccomandato da Martin Geisler: Se il changeset è stato in qualche modo pubblicato, tornerà (probabilmente) al tuo repository ad un certo momento perché hai solo cambiato il tuo repository locale.

Dopo hg update -r REVaverlo utilizzato non era chiaro nella risposta su come eseguire il commit di tale modifica in modo da poter quindi spingere.

Se provi a eseguire il commit solo dopo l'aggiornamento, Mercurial non pensa che ci siano cambiamenti.

Ho dovuto prima apportare una modifica a qualsiasi file (diciamo in un README) in modo che Mercurial abbia riconosciuto che avevo apportato una nuova modifica, quindi potevo commetterlo.

Questo ha quindi creato due teste come detto.

Per liberarmi dell'altra testa prima di spingere, ho seguito il passaggio No-Op Merges per porre rimedio a quella situazione.

Sono stato quindi in grado di spingere.

Le risposte sopra sono state molto utili e ho imparato molto. Tuttavia, per le mie esigenze la risposta sintetica è:

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

dove ${1}è il numero della revisione o il nome del ramo. Queste due righe fanno effettivamente parte di uno script bash, ma funzionano bene da sole se si desidera farlo manualmente.

Ciò è utile se è necessario aggiungere una correzione rapida a un ramo di rilascio, ma è necessario crearlo per impostazione predefinita (fino a quando non si ottengono i nostri strumenti CI corretti e in grado di costruire dai rami e successivamente eliminare anche i rami di rilascio).

Installerei Tortoise Hg (una GUI gratuita per Mercurial) e la userei. Puoi quindi fare clic con il pulsante destro del mouse su una revisione a cui potresti voler tornare - con tutti i messaggi di commit lì davanti ai tuoi occhi - e "Ripristina tutti i file". Rende intuitivo e facile scorrere avanti e indietro tra le versioni di un set di file, il che può essere davvero utile se stai cercando di stabilire quando è apparso per la prima volta un problema.