2. Sistema de controle de versão
• Um sistema de controle de versão (ou versionamento), VCS (do inglês version control system) ou
ainda SCM (do inglês source code management) na função prática da Ciência da Computação e
da Engenharia de Software, é um software com a finalidade de gerenciar diferentes versões no
desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados
no desenvolvimento de software para controlar as diferentes versões — histórico e
desenvolvimento — dos códigos-fontes e também da documentação.
• Entre os mais comuns encontram-se as soluções livres: CVS, Mercurial, Git e SVN; e as
comerciais: SourceSafe, PVCS (Serena) e ClearCase. O desenvolvimento de software livre prefere o
SVN que vem substituindo o clássico CVS. Muitas empresas também adotam o SVN, embora
algumas empresas prefiram uma solução comercial, optando pelo ClearCase (da IBM) ou
SourceSafe (da Microsoft). Optar por uma solução comercial geralmente está relacionada à
garantia, pois as soluções livres não se responsabilizam por erros no software e perdas de
informações1 , apesar das soluções livres poderem ter melhor desempenho e segurança que as
comerciais. As soluções comerciais apesar de supostas garantias adicionais não garantem o sucesso
da implementação nem indenizam por qualquer tipo de erro mesmo que comprovadamente
advindo do software.
• A eficácia do controle de versão de software é comprovada por fazer parte das exigências para
melhorias do processo de desenvolvimento de certificações tais como CMMI e SPICE.2

3. Principais vantagens
• Controle do histórico: facilidade em desfazer e possibilidade de analisar o
histórico do desenvolvimento, como também facilidade no resgate de
versões mais antigas e estáveis. A maioria das implementações permitem
analisar as alterações com detalhes, desde a primeira versão até a última.
• Trabalho em equipe: um sistema de controle de versão permite que
diversas pessoas trabalhem sobre o mesmo conjunto de documentos ao
mesmo tempo e minimiza o desgaste provocado por problemas com
conflitos de edições. É possível que a implementação também tenha um
controle sofisticado de acesso para cada usuário ou grupo de usuários.
• Marcação e resgate de versões estáveis: a maioria dos sistemas permite
marcar onde é que o documento estava com uma versão estável, podendo
ser facilmente resgatado no futuro.
• Ramificação de projeto: a maioria das implementações possibilita a
divisão do projeto em várias linhas de desenvolvimento, que podem ser
trabalhadas paralelamente, sem que uma interfira na outra.

4. Cliente-Servidor vs Distribuído
• Sistemas cliente-servidor trabalha com um modelo centralizado no qual
existe uma copia do código corrente em um servidor central, no qual os
usuários fazem “check-out” a fim de trabalhar localmente. Quando o
usuário termina suas alterações, ele fazer um update (para validar se houve
alterações durante o tempo que ele estava editando), lida com os conflitos
que podem ter surgido e depois faz o “check-in” para que outros usuários
possam fazer “check-out” novamente.
• Sistemas distribuídos são estruturados com ponto-a-ponto: ao invés de
repositório centralizado, todos possuem seus próprios repositórios e
sincronizam através de troca de mudança conjuntos na forma de patches,
ou por merge de ramos de códigos (branches). No entanto na pratica a
maior parte dos projetos com tamanho significante possuem uma única
ramo nomeada como principal (trunk), mas isso é uma questão social e não
técnica.

5. Distribuídos
• Fornece full backup da base de código e seu histórico com
cada ramificação de código (branches), e existem muitos
ramos de código.
• É mais fácil trabalhar uma conexão de rede, pois você pode
fazer “commit” para sua copia local do repositório.
• Colaboração direta com outros desenvolvedores fica mais
fácil, logo não é preciso passar pelo sistema central.
• Fácil criação e destruição de ramos códigos (branches), e de
tal forma conduzir experiências quando desenvolvendo.
• Alguns veem como capacitando, encorajando novos
desenvolvedores a se envolverem no projeto.
• É possível múltiplos ramos principais (trunks) de diferentes
usos (estável, desenv ou ramos de releases, por exemplo).
• Commitar, visualizar histórico e outras operações similares
são rápidos, já que não precisam acessar o repositório
central.
• Merge em geral é muito mais fácil.

6. Cliente-Servidor
• É possível ter uma única pessoa ou
entidade manter o controle do histórico
a acessos ao projeto. (Em alguns casos
visto como positivo outros negativos)
• Uma única “versão máster” do código é
mantida centralizada em vez de ter
múltiplas versões concorrentes.
• Um servidor central pode ser
arquitetado e configurado para
“tolerância a falhas”, em vez de confiar
nas maquinas de muitas pessoas.

7. Boas Práticas / Trunk
• A pasta trunk é principal área de desenvolvimento.
• Todas as atualizações efetuadas dia-a-dia são
armazenadas na pasta trunk.
• Geralmente contém os arquivos mais atuais do
projeto, bem como as correções de bugs e os
últimos recursos adicionados ao projeto.
• Branchs e tags em SVN são leves – no servidor, ele
não faz uma cópia completa dos arquivos, apenas
um marcador dizendo “esses arquivos foram
copiados nesta revisão”, que ocupa apenas alguns
bytes. Com isto em mente, você nunca deve se
preocupar sobre espaço ocupado.

8. Boas Práticas / Branch
• A pasta branch contém uma cópia de determinada
revisão de trunk quando este estiver estável ou for
necessário criar uma nova funcionalidade que
posteriormente será mesclada devolta ao tronco
ou até mesmo para criar outra linha de
desenvolvimento intependente do tronco.

9. Boas Práticas / Tag
• Normalmente utilizada para lançamentos de “releases”, a tag
marca um ponto estável do desenvolvimento.
A seguir um exemplo de utilização
• Um projeto inicia e um repositório é criado. Ex.: meuprojeto 1.0.
• O projeto é desenvolvido na pasta trunk.
• Quando chega a hora de liberar uma versão, a pasta trunk é
copiada para a pasta branch e dado um nome de versão.
• Este branch é congelado e não sofre mais alterações, apenas
correções. Rigorosos testes são efetuados.
• Quando os testes efetuados encima de um branch estão
completos, a versão que se encontra no branch é copiada para a
pasta tags, formando assim um “release” ou uma versão
“liberada”. Ex.: meuprojeto 1.0.
• O projeto continua em desenvolvimento em trunk até que
chegue a hora de lançar uma nova versão. Ex.: meuprojeto 2.0.
• Havendo mais algum bug na tag “meuprojeto 1.0″, será corrigido
no branch correspondente e criada uma nova tag, evitando ter
que liberar a versão mais nova – possivelmente inacabada ou
não testada. Ex.: meuprojeto 1.1.
• Qualquer modificação em branch, deve ser copiada para a pasta
de tags, após todos os testes.

10. Mercado Subversion (SVN)
Visual SourceSafe(VSS)
CVS
Team Foundation Server (TFS)
Perforce
ClearCase
Git
PVCS
StarTeam
Vault
MKS Integrity
Mercurial
Synergy
AccuRev SCM
CA Software Change Manager
Rational Team Concert

11. Proficiência

13. Resumo
• Achar o equilíbrio entre algo comercial ou
comunitário, cliente-servidor ou distribuído, novo ou
maduro, integrado ou stand alone etc ... são algumas
das duvidas na escolha de uma solução para sua
empresa. Deixo aqui dados analíticos e quantitativos
para que você tome sua própria decisão. Lembrando
que não existe o estado da arte então busque o
equilíbrio.

14. Fontes :
• http://pt.wikipedia.org/wiki/Sistema_de_controle_d
e_vers%C3%A3o
• http://www.tuxradar.com/content/which-version-
control-system-best-you
• http://www.scalevp.com/github-the-new-locus-of-
software-development
• http://google.com.br