Best practice in versioning

responsabilità

Questa risposta non è intesa come esauriente e dettagliato libro di testo illustrato dalla serie "... per Dummies", può contenere le conclusioni sbagliate da ipotesi errate e implica la capacità del lettore di leggere e comprendere la documentazione

Prefazione

La soluzione proposta si basa sui seguenti presupposti:

• core e ogni plug-in sono progetti indipendenti separati
• ogni versione contiene un insieme arbitrario predefinito (in grado di variare da versione a versione) di singoli componenti della versione strettamente definita

Soluzione

Nella soluzione suggerita prevista e suggerito l'uso di tali opportunità di SVN, come:

• Filiali
• Esterni

Ciascun componente fornirà il proprio posizionamento: in può essere repository separato o percorso predefinito all'interno del repository comune. In ogni caso la soluzione consiste solo di collegamenti svn: componenti esterni esterni. Per ogni Componente (previo accordo) l'URL dello stato stabile è determinato e fissato per la durata dello sviluppo. Nelle condizioni di cui sopra, per semplificare la notazione e la comprensione del flusso di lavoro in futuro, utilizzare il seguente preset:

• Ogni componente ha il proprio repository
• Il punto stabile di ciascun componente è il trunk del repository
• Il Repository of Solution di seguito ha nome SuperRepo (al contrario di repository di Components, che hanno Repo/somestring/ name)

Con la presente, il nostro compito è: costruire Repo * per i componenti, compilare SuperRepo dopo di esso, dove ogni cartella è collegata al tronco del repository, revisione HEAD (non usiamo le revisioni PEG nello sviluppo di tutti i giorni).

Dopo lo sviluppo di questi passaggi continua nel solito modo, per ogni WIP per i componenti possiamo usare tutte le tecniche svn (ramificazione, tagging, unione)

Nel tempo di rilascio dobbiamo avere una mappa: quali componenti e versioni dei componenti dovrebbero (potrebbero) essere stati inclusi nella versione. La versione del componente può essere definita come numero di revisione (all'interno del componente repo) o come tag - non importa. Con questa mappa possiamo modificare il trunk di SuperRepo ( trunk! ) alle nostre esigenze (aggiungi-rimuovi elementi esterni, per usato nella release free release della release modificando la definizione esterna: aggiungendo PEG- revisione per il collegamento del trunk o modifica dell'URL al tag corrispondente) e tag il trunk lucido di SuperRepo per riferimento futuro. Esporta il tag dopo tutto per la pubblicazione

In questo modo ogni release avrà un insieme noto di componenti in stato noto e può essere facilmente assemblato come Lego

Bene, io non sono un ninja SVN o altro, ma per i due progetti, avresti semplicemente due cartelle al livello più alto. Ognuno di questi avrebbe alcune cartelle:

• Release, che avrebbe tag o copie del progetto a cui hai deciso di assegnare un numero di versione. E dovresti davvero iniziare a dare loro i numeri di versione.
• Trunk, questa non è la cartella "stable stable", ma piuttosto dove vive il codice di sviluppo principale. A un certo punto uscirai. Chiama il trunk corrente "la versione di rilascio" e lo tagga o lo copia nella cartella di rilascio. A quel punto nel tempo il tronco e il rilascio sono gli stessi, ma il tronco continua a crescere.
• Branch, è qui che viene svolto il lavoro. Se vuoi scrivere del codice o cambiare qualcosa, copri il trunk nel tuo ramo personale, toccalo con esso, testalo, (chiedi a qualcuno di revisionarlo per motivi di sanità), e poi uniscilo nel bagagliaio. E poi riprovare.

Le versioni e i tag ti consentono di tenere traccia di quale versione è compatibile con cosa. E i rami dovrebbero permetterti di sviluppare oggetti a lungo raggio e realizzare ancora correzioni di errori urgenti.

Non ho ancora provato git, potrebbe essere fantastico.