Quali convenzioni di denominazione utilizzate per rami e tag SVN?

Question

La nostra azienda sta creando una convenzione di denominazione per rami e tag SVN e non mi piace l'idea di utilizzare solo la data o il numero di build sui nomi di rami/tag.

Penso che abbiamo bisogno nomi che porta una maggiore definizione su ciò che questo percorso rappresenta, quale sforzo è stato fatto, ecc

Cosa pensi/usare?

Answer 1

Tutte le attività dello sviluppatore vanno in un sistema di tracciamento dei bug. Questo sistema di tracciamento dei bug ha ID associati a ciascuna attività.

Così, per il nome del ramo di qualsiasi compito, usiamo:

ticketId_TicketSubject

Quando un ramo contiene più ticketIds abbiamo appena combinarle nel nome del ramo:

ticketId1_ticketId2_Description

In questo modo se sei in un biglietto e vuoi sapere quale ramo costruire, puoi facilmente cercarlo. Allo stesso modo, se vuoi trovare il biglietto con la tua filiale, puoi facilmente trovarlo anche tu.

Per i tag, viene contrassegnato dal numero di versione stesso.

Per quanto riguarda la posizione di ogni ramo. Abbiamo una gerarchia di livello superiore in questo modo:

/branches

/tags

/trunk

Poi tutti i nostri prodotti/progetti vanno sotto ciascuno di coloro che sono dentro le proprie sottocartelle.

/trunk/project1/

/branches/project1/TicketId_Description

Answer 2

Per un ramo di caratteristica, nome dopo ciò che viene fatto. Ad esempio, ho spostato il nostro ORM da LINQ a SQL a NHibernate e creato un ramo chiamato "NHibernate". Una volta completato il ramo e reinserito nel tronco, è possibile eliminare il ramo per salvare i conflitti di denominazione in futuro. Se hai davvero bisogno di recuperare il ramo che puoi, devi solo tornare alla storia e ripristinarlo.

Se si dispone di numeri di trama/preventivo/lavoro rilevanti per un ramo, lo aggiungerei al nome del ramo es. "NHibernate_429" in modo che tu possa facilmente fare riferimento al tuo sistema di tracciamento. Tuttavia, vorrei sempre andare prima con l'inglese, perché è quello che le persone fanno più realisticamente per riferirsi ad esso quando è in fase di sviluppo.

Per cose come i tag è difficile dire cosa si vuole fare in quanto dipende da cosa si sta taggando. Se stai taggando le versioni, utilizzerei "Release X.X.X.X "o qualcosa di così semplice.Non ti interessa davvero quale sia la data o il numero di build quando stai guardando indietro per una versione specifica come esempio

Answer 3

Che cosa usiamo (principalmente seguendo la convenzione accettata) :

projectName 
| 
--trunk 
| 
--tags 
| 
--branches 

Sotto tronco abbiamo il tronco principale

Sotto tag abbiamo tag ogni rilascio (entrambi, rilasci test interni e rilasci dei clienti) ci usiamo il numero di versione, come il nome del tag

...

Sotto i rami abbiamo o ne ramo per ogni versione principale che abbiamo rilasciato (nel nostro caso il risultato di una iterazione di XP). Quelli sono nominati come la versione principale ("v5.03", "v6.04"). Inoltre, abbiamo filiali interne per modifiche importanti o versioni speciali. La denominazione è in forma libera e il nome dovrebbe dire alla gente ciò che rappresenta il ramo. Gli esempi sarebbero "workaround_customerA", "module_x_reorg" ecc.

Answer 4

Diamo ai nostri sportelli una versione ".X", in cui i tag hanno un numero.

Ad esempio, il ramo sarebbe Foo-1.2.3.X, ei tag sarebbe Foo-1.2.3.1, Foo-1.2.3.2, ecc

Abbiamo anche un tag speciale, Foo -1.2.3.0, che viene creato non appena il ramo viene creato dal trunk, prima di qualsiasi modifica. È così che possiamo diffare rami e tag allo stato iniziale in qualsiasi momento (poiché in un paio di giorni, il trunk potrebbe essere diverso). Questa pratica ha reso le fusioni un po 'più semplici, e rende molto più facile capire quale codice è cambiato nel ramo.

Answer 5

Prefisso sempre i tag (e di solito anche i rami) con la data nel formato AAAAMMGG seguito da una descrizione dello scopo del tag o del ramo.

esempio, 20090326_Release_v6.5 o 20090326_Post_Production_Update

Questo è sotto il tronco/tags/rami Hierarchy Standard naturalmente.

Il prefisso data assicura che tutti i tag o rami siano visualizzati nell'ordine di creazione, che è molto più utile che essere ordinati per descrizione se si esegue la scansione attraverso una grande cartella di tag. Si vede la timeline di quando e perché sono stati creati (come i messaggi di mini-log).

Answer 6

Bene, la ramificazione è praticamente aperta, poiché ci sono diversi tipi di rami, la loro denominazione può essere molto diversa.

Vale la pena ricordare cosa ti dà il controllo del codice sorgente. I nomi dei tag non sono solo "v1.4", è "/CashCowProject/tags/v1.4". Denominare un tag "/CashCowProject/tags/CashCowProject-v1.4" è un po 'ridondante, che altro sarebbe?

Il controllo di revisione consente inoltre l'accesso completo alle date e alle ore di creazione dei tag. Il controllo di revisione fornisce anche messaggi di commit da utilizzare, in particolare la prima riga.

Date tutte queste informazioni, non è difficile mettere insieme una visione semplice dandovi tutte le informazioni necessarie, provenienti da fonti coerenti e adeguati, come ad esempio:

CashCowProject 
    v1.4 - 26 March 2009  : With Added whizzbang (more) 
    v1.3 - 13 February 2009 : Best graphics!  (more) 
    v1.2 - 01 January 2009 : Upgraded security (more) 

L'unica cosa che il nome del tag è davvero utile perché qui è il numero di versione.Se stai cercando di inserire tutte le informazioni nel nome di un tag, è un po 'prolisso e scommetto che non sembrerà così bello.

Answer 7

Meglio:

<projectname>_<Year>_<minor>_00 

come:

XYZ_14_01_00