Dipende dal tagging CVS per le build automatizzate

C'è un aspetto che potresti voler prendere in considerazione. Per lo stato CVS viene mantenuto per file - per lo stato git viene mantenuto per l'intero repository.

Questo significa che le operazioni di sondaggio e aggiornamento sono molto, molto più veloci in git che in CVS, e che abbiamo fatto un'enorme differenza per il nostro motore di Continuous Integration quando siamo passati.

Inoltre, sono abbastanza certo che qualunque cosa tu faccia in CVS, può essere modellata anche in altri sistemi, o adattata per funzionare meglio.

EDIT: Come richiesto, il mio commento su come emulare questo flusso di lavoro con git: "Hai un repository e lavori su master (git lingo per HEAD). Poi hai un ramo QA dove ti unisci dal master come necessario e un ramo PROD in cui unisci il QA in base alle esigenze, registrando la revisione (SHA1) del commit su cui lavori con la build in modo da poterla riprodurre in modo appropriato dato un ID di build. "

utenti di bzr e hg, sentiti libero di tradurre come appropriato.

Sia git che subversion supportano il concetto di tag, ma dal momento che entrambi consentono di fare riferimento a lo stato dell'intero codice base in qualsiasi momento, non dipendono da esso. CVS ti consente di estrarre il codice da un momento specifico, quindi puoi utilizzare un riferimento temporale per la contabilità anziché fare affidamento sui tag.

Però ci sono altri validi motivi per aggiornare da CVS.

Sembra un profilo o una situazione di classificatore

Tipicamente, il processo di rilascio di Maven implica il tagging del codice sorgente che è stato usato per costruire l'artefatto. Ad esempio, supponiamo che tu stia creando un artefatto di guerra. Il processo di rilascio essenzialmente effettua le seguenti operazioni:

1. Verifica che la build corrente non dipenda da alcun build SNAPSHOT (dato che potrebbero cambiare in qualsiasi momento e influenzare il codice di produzione)
2. Aggiorna pom.xml per fornire un numero di versione che rappresenta la versione (ad esempio 0.0.1-SNAPSHOT diventa 0.0.1)
3. Controlla pom.xml aggiornato nel controllo della versione e contrassegna tutti i sorgenti con il numero della versione (ad esempio cvs / tags / 0.0.1)
4. Distribuisce la risorsa costruita nel repository di rilascio in modo che i team possano condividerla

In Subversion, questo approccio è completamente supportato attraverso il normale processo di tagging. Non posso commentare Git, temo.

E per la nostra situazione con ambienti speciali?

Tipicamente, Maven incoraggia l'uso di un singolo artefatto rilasciato che non cambia mentre si muove attraverso ambienti diversi (si pensi alla configurazione esterna attraverso i file di proprietà e / o JNDI). Se si riscontra un problema all'interno di un artefatto rilasciato, viene reindirizzato agli sviluppatori (che ora stanno lavorando su 0.0.2-SNAPSHOT) e 0.0.1 è effettivamente in scatola. Gli sviluppatori riprovano con 0.0.2 e così via. Ci sono ovviamente delle varianti, ma questo è un approccio comune.

Se i tuoi artefatti devono essere diversi per ogni ambiente, allora Maven può creare un artefatto differente basato su un'impostazione di profilo (molto personalizzabile) o un classificatore. Dalla documentazione di Maven :

The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.

Another common use case for classifiers is the need to attach secondary artifacts to the project's main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files.