CVS+Branch+Divisão Sistema

Pode não, DEVE !

Uma estrégia (não a única) é ter novos desenvolvimentos no ramo pricipal (HEAD). Quando vc. fizer uma entrega para o cliente, crie um TAG e gere a versão a partir de um checkout do TAG.

Se vc. tiver que fazer uma manutenção nesta versão, crie um fork usando o TAG inicial como base. Antes de entregar a nova versão, crie um TAG e faça um build limpo a partir de um checkout do TAG.

Mesmo que vc. nunca venha a fazer o merge, ao menos vc. poderá ter uma idéia clara da evolução de determinada classe.

seria interessante você se planejar a estabelecer um módulo que pudesse configurar isto, senão você vai ter muito trabalho manual, a não ser que você esteja se beneficiando de scripts bash ou bat, como por exemplo.

pode sim. mas um dia você necessitará fazer um merge. um branch não deve ter um ciclo de vida longo, a não ser que seja por uma boa causa.

uma idéia para você evitar seria como falei logo no começo. vc pode manter um repositório para release por dois branchs, mas lembre-se que você não se beneficiará de uma correção compartilhada ou manutenção em núcleo do sistema

neste ponto de vista não.

editado: uma boa dica também como o colega mencionou, é você procurar gerar builds internos e externos para teste de forma que você possa passar uma TAG a fim de garantir o estado mantido daquele build, e se caso alguém necessite de uma correção daquele build, você pode criar uma branch a partir desta TAG só para correções, voltando a lembrar que quanto mais branch’s mais merge, portanto mais tempo no seu projeto e mais custo. Seu gerente vai adorar isto!

Uma proposta interessante que achei ao uso do merge foi o redbase disponível pelo git.

dá uma olhada neste vídeo da softwaretesting que exemplifica o ciclo de vida de um build de release de software. (é um caso extenso e bem definido, não sendo necessário aplicar todos os pontos)

Bom dia,

Muito obrigado pelas informações.

Vou dar uma lida nos sites que vocês indicaram.

VLW!!!