Come gestite le modifiche minori che volete mantenere locali in Mercurial?

Sto pensando di migrare un repository cvs di 14 anni (storia intatta) su mercurial. Penso di avere tutti i bit di conversione tecnica giù, ma ho ancora alcune domande su come lavorare efficacemente in mercurial.

Una delle cose che vedo molto nei sandbox cvs dei singoli sviluppatori (incluso il mio) sono le modifiche locali senza commit che non sono pronte per essere portate sulla linea principale. La mia comprensione è che questa è una brutta cosa. La maggior parte dei miei esperimenti con hg suggerisce che i cambiamenti non impegnati sono una brutta cosa da avere. L'incapacità di fondersi con loro è sufficiente per questo. Quindi quello che voglio sapere è come le altre persone che usano mercurial nella programmazione quotidiana lo affrontano. Come gestisci le modifiche incomplete al codice quando arriva il momento di aggiornare il tuo repository? Come gestisci le modifiche locali che non vuoi (ancora) condividere con altri sviluppatori?

Lo gestisco in questo modo:

Nel mio repository locale, commetto ogni modifica, anche se sto sperimentando. Se sto bene con l'esperimento, ed è testato, lo spingo nel repository remoto. In caso contrario, rimane nel mio repository locale (o torna a una versione precedente).

L'idea è che il repository remoto contenga solo versioni funzionanti e testate dei miei progetti.

Ci sono un paio di cose che aggiungerò.

Uno è quello di suggerire un flusso di lavoro che faccia un uso giudizioso di shelve , fornito di serie con TortoiseHg .

Ogni volta che volevo eseguire il commit di parte della mia directory di lavoro corrente, accantonavo le modifiche che non volevo impegnare, ricompilare (per assicurarmi di non aver archiviato i bit che ora risultano in una compilazione interrotta) e quindi eseguire i miei test . Quindi commetterei il set completo, funzionante e testato. Alla fine avrei eseguito unhelveelve per ripristinare le mie modifiche.

Se avessi avuto cambiamenti piuttosto permanenti, supponiamo che volessi che un file di configurazione sulla mia macchina di sviluppo fosse sempre puntato sulla porta localhost 3333 anziché sul server di produzione, quindi avrei cercato di utilizzare l'estensione Mercurial Queues, che viene fornita con Mercurial e TortoiseHg .

Non credo che i cambiamenti non confermati siano intrinsecamente una cosa negativa. Ti riferisci a una "incapacità di unirli con loro" - se hai una modifica non impegnata in un file, e tiri e aggiorni una modifica a quel file, Mercurial avvierà il processo di unione proprio come se lo avessi commesso, quindi ti chiese una fusione. Intendevi qualcosa di diverso?

Quindi, per le modifiche locali che non vuoi ancora condividere con altri sviluppatori, hai due approcci. Il primo è mantenere le modifiche nella copia di lavoro, ma non spingerle, e l'altro è metterle da parte, fuori dalla copia di lavoro. La scelta dipende dal fatto che si desideri che queste modifiche siano disponibili mentre si lavora.

Se li conservi nella copia di lavoro, le modifiche in entrata funzioneranno correttamente, quindi devi solo evitare di creare modifiche in uscita e ciò significa evitare di commetterle. Se i file sono nuovi, è facile - semplicemente non hg addli. Se sono già tracciati, è possibile escluderli specificatamente da commit con hg commit --exclude foo.txt. Se hai un gran numero di file da escludere o li escluderai da molti commit (ad es. Per una modifica permanente a un file di configurazione locale), guarda l' estensione di esclusione .

Se sei pronto a spostare le modifiche da parte, hai un'altra serie di opzioni. La cosa più semplice è semplicemente usare hg diffsui file per produrre una patch che li descriva, che tenete in un posto sicuro, quindi hg patch --no-commitriapplicare quella patch quando si desidera ripristinare le modifiche. Puoi renderlo più fluido installando l' estensione shelve , l' estensione della soffitta o qualche altro parente. Potresti anche usare l' estensione delle code , ma che sta usando una mazza per rompere un dado. Potresti anche solo eseguire il commit delle modifiche, quindi aggiornare di nuovo al genitore e impegnare altri lavori lì, lasciando le modifiche in un ramo anonimo tozzo hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')(anche se potrebbe essere più facile fare manualmente!). Dovresti quindi fare attenzione a non spingere quel changeset, però.

Vengono utilizzati due approcci di base per separare i flussi di sviluppo.

• Filiali nominate. L'idea è che lavori sul tuo ramo, il nmichaels_branch_of_awesome. In questo modo puoi impegnare i tuoi cambiamenti senza friggere il lavoro degli altri. Quindi ti unisci ad altre persone quando hai bisogno del loro lavoro e quando arriva il momento per la funzionalità, passi al ramo più stabile per l'integrazione. Preferisco i rami con nome.

• Clone anonimo. Questo crea un repository separato per il tuo sandbox. Qui si gioca fino a quando non si ottiene quello che si desidera, quindi (probabilmente) si esegue una patch MQ per i propri commit e si passa al punto di partenza. Non sono così appassionato di questo approccio, in quanto richiede la gestione delle directory e potenzialmente un lavoro MQ, che può essere complicato. E con alcuni repository, possono iniziare a diventare solo un po ' grandi per questo. Detto questo, questo sembra essere preferito dagli sviluppatori Kiln.