2010-03-24 22 views
22

Il mio progetto corrente è suddiviso in 3 parti: Sito Web, Desktop Client e un plug-in per un programma di terze parti. Inizialmente avevamo iniziato con Subversion per il controllo del codice sorgente, ma abbiamo deciso di provare Mercurial dopo aver letto Joel Spolsky's final post. Considerando che non abbiamo usato la maggior parte del potenziale di svn in precedenza, abbiamo pensato di iniziare con alcune idee di base su come il controllo del codice sorgente avrebbe reso facile questa transizione.Strategia Mercurial Tagging/Branching

Tuttavia, dopo aver impostato il nostro repository iniziale, ci siamo persi su come il tagging e il branching dovrebbero funzionare su un progetto come questo.

In sostanza, stiamo lavorando su tutte e 3 queste parti allo stesso tempo. Vogliamo che una versione sia una combinazione delle 3 parti. Attualmente stiamo lavorando in un repository.

Per la parte plug-in, abbiamo terminato la prima iterazione a cui ci siamo riferiti come plug-in v0.1. Per la prima build ufficiale delle altre due parti, vorremmo anche fare riferimento a loro come Sito Web v0.1 e Desktop Client v0.1. Quando tutte e tre le parti sono alla v0.1, vorremmo avere un progetto completo v0.1.

Il nostro problema è che non siamo sicuri di come gestire tutto questo nel repository Hg. Il modo migliore per gestirlo sarebbe creare 3 repository separati per le 3 versioni stabili e quindi altri 3 repository per gli attuali sviluppi? Attualmente abbiamo questo tutto in un repository. Dovremmo farlo nei rami (sono rami diversi dai repository di clonazione?) E tag?

Qualsiasi aiuto è molto apprezzato.

+0

Ho recentemente iniziato a considerare anche Hg e questi erano praticamente la stessa riga di domande che avevo. –

risposta

8

Sembra proprio che tu voglia repository separati per le 3 parti, se hai bisogno di legare i 3 insieme nelle versioni potrebbe essere utile avere questi 3 repository come subrepos di un repository complessivo del progetto.

0

Provare a utilizzare Joel's Tutorial on Mercurial. Questo potrebbe dare un po 'di più o come usarlo. Non c'è davvero un "Branching" come usato in SVN e, in realtà, potrebbe essere una buona idea smettere di provare ad usare Mercurial come se fosse SVN. Invece di Branching, hai i tuoi repository locali.

+2

L'avvio di un nuovo repository per ramo è solo UNA delle possibilità supportate da Mercurial. –

19

Consiglio vivamente il blog di Steve Losh A Guide to Branching in Mercurial, dove descrive diversi approcci alla ramificazione supportati da Mercurial.

L'utilizzo della funzione di diramazione denominata Mercurial è probabilmente la corrispondenza più simile alla ramificazione con SVN.

5

È possibile conservarli in un repository o separare i progetti. Per me, dipenderebbe dalla quantità del codice, se presente, condivisa tra le applicazioni. Se il codice non è condiviso tra i componenti, utilizzare un repository diverso per ciascuno.

Repository separati consentono di taggare facilmente ciascun componente con la versione (v0.1) e quindi proseguire con lo sviluppo in base alle esigenze. Quando sei pronto per il rilascio di un prodotto combinato, estrai il tag desiderato per ciascun repository e otterrai la versione completa del prodotto. Se si dispone di risultati finali per l'applicazione che non sono correlati a nessuno dei tre componenti, è anche possibile creare un repository per il prodotto combinato per conservare tali dati. È possibile gestire la ramificazione per ciascuno dei componenti attraverso filiali o repository clonati.

Se si conservano i componenti in un unico repository, funzionerà comunque, ma i tag e i rami diventeranno molto più disordinati. Quando il plug-in arriva a v0.1, crea un tag simile a "plug-in v0.1". Fai la stessa cosa per i client desktop e web. Quindi, quando si desidera rilasciare il prodotto, sarà necessario estrarre da tre tag diversi che hanno ciascun componente alla v0.1.

Vorrei optare per i repository separati. La decisione è più complicata se esiste un codice condiviso, ma potresti trovare il modo di prendere le tue dipendenze come librerie piuttosto che come codice.

Per le vostre domande sulla ramificazione, this article è una buona guida per le diverse opzioni e pro/contro.