Come mantenere le modifiche non salvate in un repository Mercurial locale, pur continuando a spingere / tirare?

Question

Se sto lavorando su alcuni file di cui non voglio eseguire il commit, li salvo. Poi ho altri file che voglio inviare al server, tuttavia se qualcun altro ha apportato modifiche al repository e li tiro giù, mi chiede di unire o rebase .. ma una di queste opzioni mi causerà perdere le mie modifiche locali che non ho impegnato .

Cosa stanno facendo gli altri per aggirare questo problema? Trovo che la documentazione per l'estensione shelving sia difficile da capire.

Nota: sto usando Mercurial Eclipse per eseguire il push e il pull dei file da / verso il server.

Qualsiasi spiegazione in merito sarebbe molto apprezzata! Grazie!

---

Esempio:

Sto lavorando al mio sito web in Mercurial Eclipse. Ho una nuova cartella e nuovi file che non voglio ancora inviare al server. Ho anche modificato alcuni file esistenti e non voglio ancora rendere effettive queste modifiche.

Poi qualcosa sul mio sito web si interrompe e ho bisogno di aggiustarlo, non mi permetterà di aggiustarlo senza ribasare o unirsi con il suggerimento più recente del repository e questo mi farà perdere tutte le mie modifiche non salvate.

Cosa devo fare con la mia nuova cartella e i file che ho modificato se non voglio perderli? La ri-clonazione sembra noiosa. Anche la copia dei file in una nuova cartella sembra noiosa. Sono sicuro che Shelving o MQ faranno quello che voglio, semplicemente non so ancora come farlo.

Answer 1

Sono sicuro che qualcuno ti aiuterà a trovare una soluzione alternativa sbagliata, ma la strada migliore è cambiare i tuoi obiettivi: impegnati e basta.Il codice che non è stato eseguito il commit non è stato scritto.Se positivamente non riesci a sopportare di avere frequenti commit nella tua cronologia, usa Mercurial Queues con un repository di code e invialo.Puoi quindi inserire i changeset, spingere / tirare / unire e reinserirli, e tutto il tuo prezioso lavoro verrà impegnato nella coda delle patch.

Answer 2

Con riferimento alla tua situazione di esempio, ecco cosa farei (seguendo la strategia di Ry4an di impegnare solo le cose su cui stai attualmente lavorando, ma non vuoi già pubblicare):

Supponiamo che inizi a lavorare in un repository come questo:

$ hg status -A
C f1
C f2
$ hg glog
@  changeset:   1:7f3c6c86a92f
|  tag:         tip
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Cioè ci sono 2 file e 2 commit / changeset. Fai un po 'di lavoro, diciamo che aggiungi una nuova funzionalità e quindi la tua copia di lavoro potrebbe assomigliare a questo:

$ hg status
M f2
? f3
? f4

Sono presenti 2 file nuovi e 1 file modificato. Ora devi correggere un bug per il quale hai bisogno anche di nuove modifiche in un repository remoto. Crea un'istantanea del tuo lavoro corrente eseguendo il commit ed eseguendo il pull delle modifiche remote (in quale ordine lo fai non ha importanza, un pull per impostazione predefinita non tocca lo stato della tua copia di lavoro):

$ hg commit -A -m "snapshot feature work"
$ hg pull

Ciò potrebbe risultare in una cronologia come questa:

o  changeset:   3:2284ba62de07            <-- just pulled in
|  tag:         tip
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| @  changeset:   2:4a19d371a04f          <-- your interrupted work
|/   summary:     snapshot feature work
|
o  changeset:   1:7f3c6c86a92f
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Ora puoi aggiornare / controllare la revisione 3 e iniziare a correggere i bug:

$ hg update 3
.. fix the bug ..
$ hg commit -m "fix a bug"
$ hg glog --limit 3
@  changeset:   4:5d3d947fb4af
|  tag:         tip
|  summary:     fix a bug
|
o  changeset:   3:2284ba62de07
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| o  changeset:   2:4a19d371a04f
|/   summary:     snapshot feature work
:

Sembra buono, spingiamo la tua correzione, cioè rendila live, senza pubblicare il tuo lavoro intermedio:

$ hg push -r 4

Questo spinge tutte le modifiche che portano alla revisione 4, la tua correzione dei bug, ma nessun altro ramo nel tuo repository locale. Puoi anche usare -r ., che si riferisce alla revisione genitore della tua copia di lavoro, cioè la revisione che hai appena commesso.

Finalmente puoi tornare al tuo lavoro sulle funzioni e continuare il tuo lavoro:

$ hg update 2
.. work, commit, work, commit ..
.. finally merge with the other branch, e.g. revision 4

Questi passaggi si trovano sulla riga di comando, ma penso che non sia difficile adattare il concetto generale ai clic corrispondenti nel plug-in Eclipse Mercurial.

Alcune note extra:

• Potresti voler aggiungere ai segnalibri il commit dello snapshot, quindi non è necessario lavorare con ID o numeri di revisione.
• Se in un secondo momento desideri pubblicare il lavoro sulla funzione in un unico commit, utilizza l'estensione collapse una volta terminato.