1. casa
  2. Domanda e risposta
  3. unione di revisioni selezionate da un ramo all'altro in Mercurial

unione di revisioni selezionate da un ramo all'altro in Mercurial

2010-04-02 18 views
7

È possibile unire un intervallo di revisioni da un ramo a un altro in Mercurial?unione di revisioni selezionate da un ramo all'altro in Mercurial

ad es.

|r1 
|r2 
|r3 
|\___ 
| | r5 
| | r6 
| | r7 
| | ... 
| | r40 
|r41

Se voglio unire le revisioni 6 & 7, ma non 5, nel ramo principale - è possibile?

Tale fusione può essere banale, per esempio, se R5 file che non sono modificati in 6 & 7 (e così i suoi cambiamenti, se non necessario, possono essere ignorati)

Che dire multipla revisione selezionata modificato va dal ramo A al ramo B? per esempio. unire 4-7, 20-25 e 30-34?

(questo non è un vero e proprio caso, solo un esempio. Sto cercando di capire se hg ha questa funzione di unione revisione raggio che so svn ha)

fonte

2010-04-02 Assaf Lavie

risposta

7

La semplice risposta è no .

Questo è contrario allo spirito di Mercurial.

Il grafico implica che 6 dipende 5 quindi tutto ciò che tira 6 dovrebbe tirare 5 anche altrimenti non ha senso.

Mi sembra di aver sbagliato Mercurial qui. Se l'albero delle modifiche è lineare, di solito è un segno che stai usando Mercurial come se usassi CVS o SVN.

La modifica albero dovrebbe essere più simile a:

4 
/\ 
/| |\ 
/| | \ 
5 7 23 \ 
| | | 25 
6 8 24 | 
     26

E poi si potrebbe tirare sia il ramo a partire 5 o quello a partire da 23.

Ora, l'errore è umano, quindi esiste una "funzione" chiamata esportazione, che consente di creare un semplice file diff da un changeset.

Nel vostro caso specifico, si farebbe in tal modo:

  • clone del repository fino a r4
  • creare un diff da r6 e uno da r7 (esportazione)
  • applicano sia (in ordine) su il nuovo clone (importazione)
  • gestiscono il test di unità fino a che non passano
  • commettere
  • tirare in r41
  • merge
  • gestiscono il test di unità fino a che non passano
  • commettere

Se lo si desidera, si può anche andare la strada estensione. Ci sono diverse estensioni utili per manipolare i changeset. Un set di campioni:

Qui si potrebbe ad esempio clonare il repository (importante, sempre testare questi su cloni, nel caso) e poi collassano gli intervalli a cui sei interessato in. Quindi è possibile esportarli/importarli.

fonte

2010-04-02 17:03:31

+0

Non è vero che r6 deve dipendere da r5 in modo significativo. Ad esempio, potrebbe essere che r5 modifichi solo alcuni file che altre revisioni non toccano, quindi non c'è assolutamente alcun problema a ignorare quella particolare revisione (da un punto di vista incentrato sui dati). Per favore non dare per scontato che io stia usando hg in questo modo, sto solo cercando di capire le sue capacità. –

+0

Inoltre, non ho capito cosa significhi il modo in cui l'albero dovrebbe apparire. L'illustrazione dell'albero mostra più rami con poche revisioni. È questo lo spirito di hg - avere solo rami brevi? Perché a volte hai semplicemente bisogno di un ramo separato per fare un sacco di lavoro su quello che non sta andando nel bagagliaio. Se mantieni molte versioni storiche non è possibile avere un repository per versione, quindi i rami sono l'unica soluzione ragionevole. Quindi, come suggerisci di mantenere questi rami brevi, e perché sarebbe meglio che avere più rami divergenti quando necessario? –

+0

r6 dipende da r5 perché hai detto che lo ha fatto quando hai creato il genitore di r5 r6. Se vuoi evitarlo, e sono davvero estranei, puoi 'hg aggiornare' a un altro genitore prima di fare il cambiamento 6. Se prima di fare r6 avevi fatto 'hg update r4' allora il genitore di r6 sarebbe r4, e tu potrebbe spostarlo in qualsiasi ramo dello sviluppo che già aveva r4. Nel senso più ampio del fare una modifica, chiediti "qual è il primo punto nella storia che potrei aver fatto" e poi "hg update" a quel punto. Quindi hai un changeset che può essere facilmente unito ovunque abbia senso. –

Problemi correlati

 Problemi correlati