Come impostare la spinta selettiva con Mercurial?

Question

Come impostare la spinta selettiva con Mercurial?

#1 da (3 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (1 voti)
#5 da (0 voti)
#6 da (0 voti)

4

Ho una situazione, quando sto lavorando a un progetto, ma allo stesso tempo nascono piccoli problemi che richiedono una soluzione rapida. Vorrei spingere solo le correzioni per questi problemi al repository principale mantenendo il resto a livello locale. Il problema è che, come ho già scoperto, non è possibile selezionare i pacchetti quando si spinge dal mio repository verso l'alto.

Quindi la domanda è, come impostare il mio ambiente Hg per avere una tale possibilità. Voglio conservare tutti i metadati Hg, quindi l'invio di patch in giro non è un'opzione.

BTW, se l'intera cosa può essere gestita direttamente da MercurialEclipse, sarebbe un grande vantaggio.

version-control branching mercurial dvcs

posta vartec 28.06.2011 - 13:40

fonte

6 risposte

Leggi altre domande sui tag version-control branching mercurial dvcs

Qual è l'utilità dei prevedibili SHA in git? Quali sono le conseguenze delle classi immutabili con riferimenti a classi mutabili?

score 3 · Answer 1

Penso che dovremmo farlo in questo modo:

clona il repository principale (di nuovo)
applica le tue correzioni, controlla le fonti localmente
riporta le modifiche al principale
cancella il clone (non ne abbiamo più bisogno, quindi lo eliminiamo il prima possibile)
sincronizza l'altro repository con main (unisci localmente)

score 3 · Answer 2

Questo è esattamente ciò che i rami servono - usali. In questo caso, vorrei svilupparmi nella mia filiale mentre la linea principale di sviluppo era in default. Mantieni le tue correzioni nel ramo corretto, unisci secondo necessità. Se è il tipo di app in cui il flusso di rottura e il fare un hg update fa male, è sufficiente tenere 2 copie distinte localmente, puntate sui rami appropriati. Lavorare su una correzione è costoso come un'altra istanza dell'IDE.

score 1 · Answer 3

Se la clonazione da remoto richiede davvero troppo tempo, allora questo (basato su La risposta di Adreas_D ) potrebbe essere molto più veloce:

Clona il repository locale.
Copia hgrc dal tuo repository locale al tuo clone locale (questo renderà il percorso predefinito lo stesso per entrambi i repository, quindi push / pull / incoming / outgoing punterà tutti al server)
Aggiorna al suggerimento del repository remoto.
Applica la correzione e conferma.
Metti a nudo i changeset che non vuoi spingere (potrebbe essere necessario abilitare l'estensione delle code mercurial).
Riporta le modifiche al repository remoto.
Elimina il clone (o tienilo nascosto in modo da poter eseguire questo tipo di correzione più rapidamente in futuro).
Estrai le modifiche dal repository remoto al tuo normale repository locale e unisci.

In alternativa, considera un flusso di lavoro usando i rami nominati. In questo modo, puoi spostare i changeset del ramo sul server in qualsiasi momento, in quanto non diventeranno parte del ramo default fino a quando non verranno incorporati in modo esplicito.

score 1 · Answer 4

Mercurial Queues è il modo più semplice e veloce: 1. Hai non creare (e lavorare con) cloni aggiuntivi (anche locali) 2. Hai tutte le modifiche di bugfix memorizzate solo localmente (nel repository)

Altre soluzioni (accettabili) possono essere - rami denominati (per "work in progress"); - LocalBranch estensione.

score 0 · Answer 5

Dopo aver individuato questo risponde a questa domanda , sembra che ci sia un'altra opzione.

Se fai hg push -r . allora spingerà il genitore della copia di lavoro corrente e tutti i suoi antenati, ma nient'altro. Usando questo, potresti:

Confida o accantonare eventuali modifiche non salvate.
Aggiorna al suggerimento del repository remoto.
Applica la correzione e conferma.
Spingi solo le modifiche indietro al repository remoto.
Aggiorna di nuovo al tuo responsabile locale.
Unisci la correzione del bug.

score 0 · Answer 6

Il metodo rapido sarebbe: - per aggiornare l'ultimo changeset di produzione stabile;

Apporta la modifica, quindi conferma la modifica;
Crea un tag di versione;
Esporta la patch;
Aggiorna al working changeset;
Unisci il changeset di lavoro con il tag creato in precedenza per portarlo ripristinare la correzione;

Per maggiori dettagli vedi link