2010-01-20 15 views
7

Quindi adesso sto imparando Ruby on Rails e sto lavorando al libro "Agile Web Development with Rails". Ho anche deciso che voglio dare a Mercurial una possibilità, perché ho letto su SCM distribuiti, e sembra una situazione ideale. Comunque, comunque, preferisco spingere il mio codice da remoto sul mio VPS Linux, solo nel caso in cui il mio disco fisso decida di fare un tuffo.Branching with Mercurial SCM

Quindi, la mia domanda è specifica per la ramificazione in Mercurial. In questo momento ho creato un repository remoto e posso facilmente cambiare i cambiamenti su SSH (ho anche creato un sito Nginx FastCGI che mi permette di spingere anche io). Quello che mi piacerebbe fare, comunque, è creare dei rami per ogni capitolo mentre lavoro su di loro, così posso mantenere una bella storia organizzata dei miei progressi attraverso il libro. Quindi questo è quello che sto facendo:

 
$ hg branch chapter-10 
(do chapter 10 stuff) 
$ hg commit -m "Chapter 10 complete" 
$ hg update default 
$ hg merge chapter-10 
$ hg commit -m "Merging chapter 10 into default" 
$ hg push 

Una volta che eseguo la dichiarazione spinta, ottengo questo messaggio da Mercurial:

 
pushing to ssh://myserver/hg/depot 
searching for changes 
abort: push creates new remote branch 'chapter-10'! 
(did you forget to merge? use push -f to force) 

Quindi a questo punto provo a fare un hg merge di nuovo, e mi dice che non c'è niente da unire, il che è ovviamente vero perché l'ho appena unito. Quando forzo la spinta con -f, tutto sembra a posto, e anche l'interfaccia web mostra i rami appropriati.

Per riassumere, la mia domanda è semplice: sto facendo questo nel modo giusto? C'è un modo più appropriato per farlo con Mercurial (cioè il "modo Mercuriale")? Onestamente voglio solo che il repository serva da backup. Sono un fan del modello SCM distribuito, ma a me sembra un po '"sporco" per forzare le spinte. Qualsiasi consiglio é ben accetto! Grazie in anticipo.

+0

Il tuo intento è: a) Avere una serie di punti di controllo del tuo lavoro mentre passi attraverso i capitoli o b) Avere più capitoli aperti per la modifica simultanea su rami diversi? – Tarydon

+0

L'opzione A è il mio intento qui, ma in uno scenario di squadra potrei vedere il valore anche nell'opzione B –

risposta

6

push -f è l'opzione giusta per il tuo caso, e il mese scorso è stata effettuata una discussione per aggiungere questo comando quando viene visualizzato questo avviso "push creates new remote branch": vedere issue 1513.

Tuttavia, issue 1974 (questo mese) menziona alcuni effetti indesiderati (non nel tuo caso però).
Vedere questo translated article per ulteriori informazioni sulla creazione di una seconda testata su un repository remoto.


Sul punto più generale, è possibile utilizzare ramo se si sta scrivendo il capitolo in parallelo, e si desidera unire loro solo a un certo punto (stabile) nel tempo

Ma se il tuo processo di scrittura è più lineare, è possibile utilizzare solo un ramo e inserire alcuni tag lungo la strada.
Tuttavia, se dovessi tornare al capitolo 10 e aggiungere alcune linee, anche se hai già inserito i tag 11 e 12, ciò renderebbe la storia più difficile da leggere.Quindi i rami sono ancora una buona idea in questo caso.

+1

Grazie per i collegamenti. Molto informativo. Sembra che sto cercando di utilizzare i rami in cui i tag potrebbero essere più adatti. –

4

Non so il tuo problema specifico, ma dai tuoi commenti sembra che tu usi i rami dove probabilmente volevi usare i tag.

I rami vengono generalmente utilizzati quando più persone collaborano allo stesso progetto e si desidera creare una separazione del lavoro in modo che una persona possa lavorare su una parte di codice stabile, mentre l'altra fa qualcosa di sperimentale che interrompe temporaneamente la funzionalità. In alternativa i rami vengono utilizzati per stabilizzarsi per il rilascio, mentre lo sviluppo sta avvenendo nel tronco.

I tag (o le etichette) vengono utilizzati principalmente per creare un marker che indica un'importanza per la versione del codice. Ad esempio, se si desidera contrassegnare il completamento del capitolo 10, è sufficiente contrassegnare tutte le versioni correnti con un tag "chapter-10". Non c'è bisogno di ramificarsi. Puoi diramarti da una versione con tag in qualsiasi momento in futuro se fosse necessario per qualche motivo.

+0

Accetto. Dato che puoi sempre tornare indietro e dirigerti da qualsiasi luogo tu debba, la creazione di rami in anticipo sembra un caso chiaro di YAGNI. –

2

In questo caso ritengo che sia del tutto normale usare -f per la spinta. Crea solo nuovi rami, non teste. La creazione di teste remote è completamente diversa.