Layout del repository Mercurial per più rami

Question

Ho un numero di progetti quasi correlati che voglio controllare versione. In SVN Io li impostato come più directory all'interno di un unico progetto

/scripts #updates in sync with project1 & project2 
/project1 #requires database 
/project2 #requires database 
/database 

Naturalmente altri layout SVN sono possibili per questo esempio giocattolo, ma questo layout ha dei vantaggi:

• posso copiare i file tra i rami preservando la cronologia
• Posso controllare solo un sottoinsieme di progetti, ad esempio svn co repo/project2; svn co repo/database. Questa operazione consente di risparmiare una notevole quantità di spazio di archiviazione & se project1 è di grandi dimensioni.
• Facilità di gestione repository, dal momento che l'accesso degli utenti è definito una volta per tutti i progetti

Questo paradigma non mappa bene a mercuriali dal you can't clone a single directory of a mercurial repo. Quindi la mia domanda è: qual è il modo più comune per archiviare progetti grandi e strettamente correlati in modo mercuriale?

Le mie idee:

• più repository - perde cronologia dei file che si muovono tra i progetti
• Forests - sembra in fase di stallo, e io non sono sicuro di come stabile questa estensione è
• rami denominati con la maggior parte contenuto non correlato
• SubRepos - Sfortunatamente sto utilizzando Ubuntu 9.04, che spedisce solo hg 1.1.2. Altrimenti questa sembrerebbe una buona opzione

Answer 1

Più repository, Forests e SubRepos sono tutte varianti sulla stessa idea. Forests e SubRepos semplificano la gestione di progetti che utilizzano anche versioni estremamente recenti di altri progetti, non risolvono il problema di base che hai, ovvero che perdi la cronologia dei file quando li sposti tra i progetti.

A mio parere, la soluzione migliore è mettere tutte le directory nello stesso repository e attendere la funzionalità Mercurial per consentire il checkout delle sottodirectory. La funzione di sottodirectory è una delle preoccupazioni del team di Mercurial, ma non è neanche banale da fare, motivo per cui non è ancora stato fatto. Conosco gli interni di Mercurial, ed è sicuramente fattibile, solo un sacco di lavoro.

La seconda opzione migliore, sebbene la consideri davvero brutta, è l'idea dei rami che hai menzionato. Avrai comunque un'operazione di unione molto strana da eseguire ogni volta che desideri copiare i file tra i rami.Potrai eseguire queste operazioni:

1. Update per capo del ramo che si desidera copiare il file in: hg update -C project1
2. Merge nel ramo che si desidera copiare il file da: HGMERGE=/bin/false hg merge -r project2
3. Revert alla testa del ramo che si desidera copiare il file in: hg revert -a --no-backup -r project1
4. ripristinare il file specifico che si desidera copiare dalla revisione capo della fusa nel ramo: hg revert --no-backup -r project2 path/to/file/in/project2.txt
5. spostare il file in esso è posto nel ramo che si desidera copiare esso a: hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
6. Segna la fusione così come deliberato: hg resolve -am
7. E infine commettere il risultato: hg commit -m "A merge to copy project2.txt to project1."

Come ho già detto, molto brutto. E potrebbe benissimo funzionare bene in hg 1.3 poiché so che alcuni bug importanti nell'interazione tra ripristino, fusione e risoluzione sono stati risolti abbastanza recentemente. (IMHO, sospetto che Ubuntu sia intenzionalmente indietro sulle versioni dei sistemi di controllo di versione non bzr.)

Quanto spesso ti aspetti di copiare i file tra i progetti? Perché dovrebbe succedere? Sei sicuro che perdere la storia sarebbe una cosa brutta?

Ho fatto qualcosa di simile in Subversion per un paio di progetti personali, ma la mia esperienza è che il mio iniziale sentimento sul progetto a cui realmente apparteneva era di solito corretto, e quando non era preservare la storia non era È davvero un grosso problema dal momento che la storia era davvero rilevante solo per il progetto originale in cui il file era in ogni caso.