Toda a confusão decorre da diferente semântica que a MS usa para "Build number" e especialmente "Revision". Os termos significam apenas coisas diferentes.
A maioria das pessoas (inclusive eu) usa um esquema de numeração de versão semântica , onde você obtém um número BUILD maior sempre que precisar criar uma nova versão para qualquer razão. Para nós, um hotfix é considerado apenas outra alteração de código, e a parte BUILD aumenta automaticamente com cada execução de CI. Módulos com os mesmos MAJ.MIN.REV são considerados intercambiáveis, e o BUILD informa qual é o mais recente.
Incrementar REVISÃO, no entanto, indica um novo ramo de lançamento permanente, é por isso que o colocamos antes do BUILD. A desvantagem dessa abordagem é que podemos obter a seguinte sequência de eventos:
- número de confirmação 4711: Alice adicionou o recurso A
- CI produz build 1.2.3.100
- número de confirmação 4712: recurso modificado por Bob B
- número de confirmação 4713: recurso fixo de Alice A (o "hotfix")
- CI produz build 1.2.3.101

Comovocêpodever,ohotfixnãoéaúnicaalteraçãocontidanapróximacompilação,eamodificaçãodeBobtambémfazpartedessacompilação.Sevocêquiserestabilizararamificaçãoatual,vocêpodeterproblemas,poisvocênuncapodetercertezaseBobacaboudeadicionaralgunsbugs.
OMSusaosdoistermosdemaneiradiferente.OnúmeroBUILDnãoéincrementadoautomaticamente,emvezdisso,podeserconsideradocomoumaespéciederamificaçãoderelease,paracongelarocódigousadoparaumaversãoespecíficadocódigo.AREVISIONindicaalterações"quentes" adicionais aplicadas a essa ramificação BUILD. A sequência seria, portanto, a seguinte:
- número de confirmação 4711: Alice adicionou o recurso A ao tronco / mestre
- Carl cria ramificação de construção
1.2.100
- CI produz compilação 1.2.100.0
- número de confirmação 4712: Bob modificou o recurso B no tronco / mestre
- número de confirmação 4713: o recurso fixo A da Alice na ramificação
1.2.100
- o CI produz a compilação 1.2.100.1

OtermoREVISÃOpodesereferira
- umarevisãodoproduto(éassimqueamaioriadaspessoasoutiliza)
- umarevisãodeumadeterminadaconstruçãodiária(éissoqueaMSfaz)
AprincipaldiferençaentreosdoisprocessosésevocêdesejaounãoacapacidadedeaplicarhotfixesàsconstruçõesdeCIe,assim,emquepontodoprocessoaramificaçãoéfeita.Esseaspectotorna-seimportantequandovocêdesejaescolherumadeterminadaversãoaqualquermomentoapóstodosostestesteremsidobem-sucedidosepromoverexatamenteessaversãoparaapróximaversãooficialdeseuproduto.
Nonossocaso,aferramentaCIcriaumatagderepositório,portanto,sempretemosasinformaçõesnecessáriasprontasparausar,quandonecessário.ComoSVN,torna-seaindamaissimples,porquetagsebranchessãoimplementadosexatamentedamesmamaneira-umatagnadamaisédoqueumaramificaçãolocalizadaem/tags
.
Vejatambém
Naseçãodeperguntasfrequentes,em Estratégia de ramificação do TFS :
In what branch should I fix the P1 (hotfix) ticket?
The P1 should be fixed in the branch that is closest to the code base running in Production. In this case the P1 should be fixed in the Prod branch. By applying the fix in any other branch and rolling out the changes to production you risk releasing semi-finished or untested code from the subsequent iterations.
Now you may argue if it is safe to work directly against the Prod branch, think again, a P1 that requires immediate attention should not be a fundamental problem in the system. In case it is a fundamental problem it should be added to the Product backlog as it may require further analysis and discussion with the customer.
Outra boa leitura é o Guia de ramificação do TFS