Casi d'uso della coda di patch Mercurial

StackOverflow https://stackoverflow.com/questions/4103733

Domanda

Utilizzo i cerotti Mercurial nei seguenti casi: -

  1. Quando ho bisogno di eseguire il pull da un repository remoto e ho modifiche in sospeso senza commit.Quindi creo semplicemente una patch, la faccio qpop, la estraggo dal repository remoto e quindi importo nuovamente la patch.
  2. Quando ho bisogno di caricare patch nelle revisioni.Faccio semplicemente una patch e la carico.

In quale altro modo potete utilizzare Mercurial Patch Queues?Sento che è un'estensione Mercurial molto potente e che non la sto utilizzando al massimo delle sue potenzialità.

È stato utile?

Soluzione

Il wiki Mercurial ha un sezione buona su casi di utilizzo:

In sintesi:

  1. Salvataggio dello stato attuale della copia di lavoro in modo da poter facilmente tornare ad esso più tardi
  2. Prevenire una "copia di lavoro aggrovigliato" - se siete a metà strada attraverso un cambiamento e vogliono cambiare qualcosa d'altro
  3. Fornire mutevoli, commette riconfigurabili in modo da poter ottenere 'storia' in cerca solo di destra prima di spingere.

Altri suggerimenti

Non c'è davvero bisogno di patch Mercurial per questo. Se si dispone di notevoli cambiamenti uncommited quando si tira, saranno fuse con la punta.

Esempio: 

C:\>hg init db
C:\>cd db
C:\db>echo >file1
C:\db>echo >file2
C:\db>echo >file3
C:\db>hg ci -Am codebase          # Create a code base with 3 files.
adding file1
adding file2
adding file3
C:\db>echo a change >>file2       # Outstanding change to file2.
C:\db>hg st
M file2

A questo punto ci clonare il database e commettiamo un cambiamento che siamo in grado di tirare. 

C:\db>hg clone . \db2
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>cd \db2
C:\db2>echo a change >>file3
C:\db2>hg ci -m "file3 change"    # Commit a change to file3.

Torna nel database originale ... 

C:\db2>cd \db
C:\db>hg st                       # Still have uncommitted change
M file2
C:\db>hg pull \db2
pulling from \db2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
C:\db>hg st                       # We have the new history, but haven't updated.
M file2                           # file2 has uncommitted change.
C:\db>type file3                  # file3 is unchanged. 
ECHO is on.
C:\db>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>hg st                       # We've updated, and file2 *still* has
M file2                           #    uncommitted change.
C:\db>type file2
ECHO is on.
a change
C:\db>type file3                  # But file3 now has committed change
ECHO is on.                       #    that was pulled.
a change

Quindi la morale è, si può solo tirare e aggiornamento, anche con modifiche non. Se ci sono conflitti di unione, un comportamento normale merge si verifica pure.

Per patch di esportazione hg export <rev> esporterà patch per la revisione.

Quando crei una coda di patch su Bitbucket, nel riquadro destro vengono elencati alcuni degli usi comuni delle code di patch.La loro spiegazione è molto buona e risponde direttamente alla tua domanda.Le citazioni da esso sono riportate di seguito.

Le code di patch sono utili per:

  • Funzionalità di sviluppo che intendi sottoporre a revisione a monte

    Poiché le patch nelle code di patch possono essere modificate, forniscono un modo ideale per sviluppare una funzione in modo tracciato sulla storia, consentendo comunque di incorporare facilmente il feedback

  • Sperimentazione con l'aggiunta di una nuova funzionalità

    Le code di patch non ingombrano la storia del tuo progetto, quindi puoi usarle in sicurezza come un modo per provare rapidamente un'idea e mantenerla nel controllo della versione, senza ingombrare la storia del tuo progetto con escursioni fallite.Se decidi di mantenere l'esperimento, puoi facilmente trasformare una coda di patch in una serie di commit mercuriali tradizionali

  • Mantenimento delle personalizzazioni private per un altro progetto

    Poiché le code di patch non fanno parte del registro delle modifiche ufficiali per un progetto, sono ideali per mantenere le personalizzazioni private per un progetto a monte.Ad esempio, potresti mantenere una coda di patch che rende il programma migliore integrare con il flusso di lavoro della tua azienda

Le code delle patch lo sono non buono per

  • Rami di lunga durata

    Poiché le code di patch sono altamente volatili, svolgono un lavoro scadente monitorando la cronologia a lungo termine del codice sorgente.Per questo motivo, le filiali di lunga data, come quelle che corrispondono alle rilasci di prodotto, dovrebbero essere mantenute in repository o filiali nominati.

  • Sviluppo del gruppo

    Le code di patch non monitorano la storia di unione, il che li rende una scelta sbagliata per lo sviluppo di gruppi, in cui si desidera davvero vedere quando una determinata serie di funzionalità è stata unita in un repository.In caso di dubbi, dovresti attenersi a una forcella tradizionale, ma padroneggiare il potere delle code di patch ti darà un'enorme flessibilità nel flusso di lavoro e ti fornirà capacità di collaborazione notevolmente migliorate.

MQ è un ottimo strumento per gestire lo sviluppo concomitante. Palese auto-plagio e l'autopromozione dalla mia :

  

3 Usare MQ con una patch (o più patch consecutivi) per progetto.

     
      
  • Pro:. Semplice e facile
    •   
  • Contro: bisogna usare qrefresh prima commutazione e ricostruire dopo; difficile   e rischioso se i progetti non sono   ortogonale.
    •   
     

4 Utilizzare un ramo MQ per progetto.

     
      
  • Pro: ultra flessibile e scalabile (per il numero di concurrent   progetti)
    •   
  • Contro: bisogna usare qrefresh e qcommit prima commutazione e ricostruire dopo;   si sente complicato.
    •   
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top