È `hg pull --rebase` analogo a` svn update`?

22

Questa domanda presuppone c'è un "beato" repository centrale che i membri di un teamÈ `hg pull --rebase` analogo a` svn update`?

clone da
spinta a quando hanno i contributi che vogliono altri membri del team per vedere
tirare da quando vogliono per vedere i contributi di altre persone.
ecc

Se è così, vorrei assumere hg update non è analoga a svn update (il motivo per cui ci sarebbero due comandi che fanno esattamente la stessa cosa?). Da quello che posso raccogliere, hg update più come svn revert. È corretto?

Aggiornamento:

mia comprensione di rebase è in gran parte basato sulla sezione "Un caso comune" in questa pagina:
https://www.mercurial-scm.org/wiki/RebaseProject

fonte

2010-03-01 allyourcode

41

Come altri hanno indicato, quasi ma non del tutto. In ordine decrescente di somiglianza svn update (e migliorando l'osservanza della DVCS generali, e in particolare Mercurial, le migliori pratiche [1]):

hg pull -u (o hg pull seguita da hg update) con le modifiche non e nessun cambiamento impegnati dal la tua ultima attrazione. Questo è il più vicino a svn update come si può ottenere, ma è piuttosto male pratica DVCS. Una delle peculiarità di DVCS è che puoi commettere le tue modifiche prima di provare a unirle con altre, e quindi avere una versione di backup per il rollback e ritentare un'unione fallita, e questa pratica lascia perdere. Non farlo
hg pull --rebase dopo aver eseguito le modifiche. Ciò attira le modifiche a monte, applica nuovamente le modifiche su di esse e consente di reindirizzare le modifiche come una cronologia lineare.Il risultato finale sarà molto simile a una cronologia delle revisioni di Subversion, ma otterrai il vantaggio DVCS di eseguire l'operazione prima della fusione. Non so come la sicurezza di questa modalità di funzionamento paragoni tra Mercurial e Git, però; in Git, le versioni pre -base delle modifiche saranno ancora presenti fino a quando non si esegue un git gc, ma Mercurial non dispone di una rete di sicurezza esplicita gc.
hg pull seguito da hg merge con le modifiche già impostate sulla copia locale. Questa è la tradizionale pratica Mercurial per fare l'analogo funzionale di svn update, nonostante la nota 1 qui sotto. Ne risulta una cronologia delle versioni non lineare, ma tutte le modifiche sono tracciate e ispezionabili.

Detto questo, non v'è molta saggezza nel pensiero di Mercurial (e di altri DVCSes) alle loro proprie condizioni, e non cercando di tradurre dal pensiero Subversion/CVS-style.

Se non siete della scuola di pensiero di riscrittura-storia-per-tenetelo-lineare. Se lo sei, probabilmente lo rebase è preferibile a update. La comunità Mercurial tende a favorire update.

fonte

2010-03-21 15:25:06

+4

Questa è un'ottima risposta. Non prova solo a spiegare hg. Cerca davvero di spiegarlo in confronto a svn, che ho specificamente chiesto nella mia domanda. Non spiega solo le differenze, che altri hanno fortemente sottolineato, spiega le somiglianze. Questa risposta cerca anche di coprire tutti i comandi hg correlati di cui sono confuso e non si concentra in modo specifico su hg pull --rebase. – allyourcode

+0

L'unica domanda di follow-up che ho avuto è stata questa: sembra che l'aggiornamento di hg sarebbe utile solo se non hai mai commesso alcun commit (come nel caso 1), perché dopo, lavorerai su un ramo che nessuno altro lo sa. Di nuovo, questo presuppone un flusso di lavoro che coinvolge un repo centrale benedetto che i membri di una squadra spingono e tirano da. – allyourcode

+1

@allyourcode Se si dispone di modifiche locali, sì, è necessario unire anziché aggiornare. Tuttavia, l'aggiornamento è anche il modo in cui si cambiano le revisioni o i rami con nome ed è utile una volta che le modifiche vengono inviate a monte. Se è necessario unire e provare ad aggiornare, l'aggiornamento avrà esito negativo, quindi di solito uso prima l'aggiornamento e unisco se fallisce. –

11

Non esattamente.

hg pull afferra le revisioni dall'altro repository e li aggiunge alle revisioni disponibili localmente nel vostro clone del repository, ma non aggiornare la propria copia di lavoro - solo il tuo repository (che, per DCVS come hg/git/etc non è la stessa cosa di una copia di lavoro).

hg update aggiorna la tua copia di lavoro effettiva all'ultima revisione nel tuo repository locale.

Questo differisce da Subversion perché in svn non esiste il "repository locale", l'unico repository è quello sul server; hai solo una copia funzionante a livello locale. Quindi, perché update è solo un singolo comando, al contrario di Mercurial pull e quindi update.

L'equivalente di svn update per Mercurial sarebbe hg pull --update, che equivale a fare hg pull e poi hg update uno dopo l'altro.

Un flusso di lavoro end-to-end per DCVS con un pronti contro termine "centrale" sembra qualcosa di simile:

Un fa hg commit su alcune modifiche.
A fa hg push per inviarli al repository centrale.
B fa hg pull per estrarli dal repository centrale nel proprio clone.
B fa hg update per aggiornare la loro copia di lavoro per riflettere le modifiche apportate al clone.

Nei sistemi senza un repo centrale, sarebbe invece simile a questa:

Un fa hg commit su alcune modifiche.
B, che ha clonato il repository di A, desidera tali modifiche, e quindi fa un hg pull direttamente dal repository di A.
B utilizza hg update per aggiornare la propria copia di lavoro alle modifiche.

Inoltre, l'equivalente a svn revert è hg revert. :)

fonte

2010-03-01 08:22:00 Amber

+1

So che hg pull --rebase è equivalente a hg pull seguito da hg rebase. Che cosa fa rebase? Will hg pull --update work se ho fatto commit a una filiale che ha commesso il fatto che il pull di hg sta scendendo? Sembra che sia a favore di rebase, per questo penso che hg pull --rebase sia analogo all'aggiornamento di svn: prende i cambiamenti da un repository centrale, li unisce alla mia copia di lavoro e cambia il genitore della mia copia di lavoro (i conflitti potrebbero dover essere risolti prima del commit). – allyourcode

+3

'rebase' fa un po 'più di quello - in realtà riscrive la cronologia dei commit per spostare i commit" privati "che sono accaduti prima di essere tirati dopo qualsiasi commit" pubblico "che è stato appena tirato dentro. Quindi, invece di dover commetti un changeset "unito", il tuo repository locale avrà già avuto tutti i nuovi changeset prima che tu abbia mai fatto i tuoi commit privati (da qui il nome "rebase" - cambierai su cosa stavi basando il tuo commit privato). – Amber

+0

Una rappresentazione grafica di ciò di cui sto parlando può essere vista su http://mercurial.selenic.com/wiki/RebaseProject sotto l'intestazione "A common case". – Amber

2

hg pull --update

sarebbe un equivalente di svn update

Come descritto in questo SO question

Il comando hg push e pull spostare modifiche tra repository e update e commit muove cambiamenti tra copia di lavoro e il tuo repository locale.

Quindi, in un DVCS, si hanno 2 nozioni invece di uno:

repo locale (pull/push)
directory di lavoro (che è l'unica rappresentanza locale della "punta" un repo con SVN)

fonte

2010-03-01 08:22:31 VonC

+1

Gestisce hg pull --update quando ho effettuato il commit su un ramo che ha commesso nel repository remoto che sto tirando giù con hg pull? Maggiori dettagli nel mio commento a Dav. – allyourcode

2

Ecco una fantastica guida per principianti al mercuriale http://hginit.com/. Dovrebbe spiegare la maggior parte delle cose chiaramente. Iniziando con "Non provare e applicare la conoscenza di svn ai vcs distribuiti"!

fonte

2010-03-01 08:29:02 Decado

+0

Questa risposta non risponde alla mia domanda specifica. Anche se non tutti i comandi hg devono avere un analogo svn, puoi comunque spiegare a cosa servono hg pull --rebase e hg update. – allyourcode

+0

Ok, Supponiamo di aver apportato alcune modifiche locali al repository. L1 'e L2' nel documento di riferimento. Invece di pensarlo come hg pull --rebase, potrebbe essere meglio pensarlo come i due passaggi hg pull e hg rebase. Quando si esegue un pull di hg dal repository "si ordina" si dirama il codice. È ancora applicato inizialmente contro la revisione che hai ritirato in origine. Lo stesso rebase applica i due set di modifiche locali dopo l'ultimo dei changeset che provengono dal pull. Questo aiuta? – Decado

+2

Tuttavia, non è necessario eseguire questa operazione con dvcs. Da qui il commento iniziale (scusate se si è rivelato essere flipent). Se leggi e capisci il documento inizialmente collegato ti renderai conto che non hai bisogno di fare il rebase. È possibile, nella maggior parte dei casi, effettuare il check-in finché si sono risolti eventuali conflitti senza ridiscutere. Il commento di Dav in alto offre un sommario piuttosto buono. – Decado

2

Il comando hg pull --rebase non è esattamente analogico a svn update, ma il risultato può essere lo stesso.

In Subversion, se si aggiorna la propria copia di lavoro si ottengono le ultime modifiche nel repository unite a eventuali modifiche locali. Quindi i file nel tuo repository sono aggiornati ma potresti ancora avere modifiche non salvate.

In Mercurial, hg pull --rebase, otterrà le ultime modifiche dal "repository centrale" (o da qualsiasi altro repository da cui si estrae) per aggiornare il repository, quindi mescolare i commit locali. Avrai comunque bisogno di un hg update per fare in modo che la tua copia di lavoro sia la stessa del tuo repository locale.

fonte

2010-03-01 12:16:17

+0

Grazie, Nick. La maggior parte di quello che hai detto ha senso per me. L'unica parte che non ho seguito è stata la tua ultima frase. Supponiamo di essere nella situazione illustrata nel secondo diagramma nella sezione "Un caso comune" in questa pagina: http://mercurial.selenic.com/wiki/RebaseProject. A quel punto, il genitore della tua copia di lavoro è L2. Stai dicendo che il genitore della mia copia di lavoro sarà ancora L2, anche dopo aver eseguito hg rebase? Stai dicendo che devo aggiornare hg a) unire le modifiche in R1 e R2 nella mia copia di lavoro, e b) rendere L2 'il genitore della mia copia di lavoro? – allyourcode

+0

Sto solo dicendo che c'è una distinzione tra la tua copia di lavoro e il tuo repository locale. Dopo il pull il "repository locale" (tutto nella directory nascosta .hg) è stato aggiornato ma la tua copia di lavoro (i file reali con cui stai lavorando) non viene modificata. L'ultimo "aggiornamento" cambierà la tua copia di lavoro per riflettere il tuo repository locale. –

+0

Si noti che il "rebase" sta lavorando sulle modifiche apportate al repository locale: non funziona su file non salvati nella propria copia di lavoro (che è diverso da svn che non ha un repository locale). –

È `hg pull --rebase` analogo a` svn update`?

risposta

Problemi correlati