2010-07-09 15 views

risposta

11

No, ho paura che abbiamo solo ponti a due vie per Subversion e Git. Non ho sentito nessuno che abbia scritto un bridge per SourceGear Vault.

Tuttavia, è ancora possibile utilizzare Mercurial sopra l' l'altro sistema. Questa è una tecnica generale che funziona per tutti i sistemi di controllo di versione (VCS). Quello che fai è il seguente:

Acquista l'ultima versione del codice dal tuo sistema di controllo delle versioni estere. Inizializzare un repository Mercurial, aggiungere tutti i file, e fare un commit:

# checkout foreign VCS 
$ hg init 
$ hg addremove 
$ hg commit 

copia Il lavoro è ormai sia una copia di lavoro Mercurial così come una copia di lavoro per il sistema esterno. Farai lo sviluppo in Mercurial e lo importerai periodicamente nel sistema estero, e periodicamente importerai le modifiche dal VCS straniero a Mercurial.

Utilizzeremo il ramo default per tracciare la cronologia del sistema esterno e un ramo denominato hg per tracciare lo sviluppo che facciamo in Mercurial.

Nota: Anton commenta che Vault mostrerà troppi file se si utilizzano i rami denominati per separare le due linee di sviluppo: utilizzare invece due cloni se questo è un problema.

lasciarlo fare la filiale hg:

$ hg branch hg 
$ hg commit -m "Started hg branch" 

È ora possibile sviluppare qualcosa:

# work, work, work... 
$ hg commit -m 'Fixed bug 42' 
# work, hack, work... 
$ hg commit -m 'Customers will love this feature!' 

Mentre si lavora insieme in questo modo, il ramo default inizierà a divergere dal ramo hg - - la differenza è esattamente le modifiche che devono ancora essere esportate nel sistema esterno. Potete vedere le differenze con

$ hg diff default:hg 

Per esportare in realtà le modifiche, si aggiorna al ramo default, unire hg in esso e confermare la modifica al sistema estero:

$ hg update default 
$ hg merge hg 
$ hg commit -m 'Merge with hg' 
# get list of renamed files: 
$ hg status --added --copies --change . | grep -A 1 '^ ' 
# commit to foreign VCS 

È possibile quindi aggiornare torna al ramo hg e continuare a lavorare con Mercurial

$ hg update hg 
# work, work, wok... 

Quando le modifiche sono fatte da altri nei VCS stranieri, è è necessario unirli nuovamente al ramo hg. Si aggiorna per la prima volta al ramo default. Ciò assicura che la copia di lavoro sembri come il VCS straniero si aspetta che assomigli. È quindi possibile aggiornare la copia di lavoro - questo rende Mercurial vedere cambiamenti, che voi commettono a Mercurial:

$ hg update default 
# update working copy using foreign VCS 
$ hg addremove --similarity 90 
$ hg commit -m 'Imported changes from foreign VCS' 

Il passo hg addremove fa in modo che Mercurial raccoglie qualsiasi cambiamento di nome che ha avuto luogo nel VCS estera.Avrai bisogno di sperimentare con il parametro di similarità per trovare un'impostazione che fa al caso tuo. Utilizzare hg status -C per vedere i nomi programmati.

A questo punto è necessario unire queste modifiche nel ramo hg in modo da poterli includere nella vostra ulteriore lavoro Mercurial-based:

$ hg update hg 
$ hg merge default 
$ hg commit -m 'Merge with default' 

Si continua a lavorare in questo modo - sempre facendo nuovo sviluppo locale il ramo hg e l'aggiornamento sempre al ramo default prima di utilizzare i comandi VCS esterni (aggiornamento, commit, ecc.).

Spero che questa guida possa aiutare te o qualcun altro! :-)

+0

Grazie per la risposta. Immagino che dovrò trovare altri modi per convincere i miei colleghi a provare il mercurio (in modo da convincere tutti la direzione che non ci piace Vault). :/ – Paulius

+0

Paulius: ho aggiunto una guida su come si usa Mercurial in modo ibrido sul VCS esistente - spero che lo trovi utile. –

+0

Sì, sembra carino. Una cosa che mi dà fastidio è che dovrei rintracciare manualmente tutti i nomi dei nomi che avrei fatto sul ramo hg e importarli in VCS stranieri. Non sono nemmeno sicuro che Vault possa trovare automaticamente i nomi. Ad ogni modo, la guida sembra buona - ci proverò. – Paulius