momento de combinar um ramo com outro e uma decisao do desenvolvedor e nao obrigatorio antes de cada commit, como acontece no centralizado.Facilidade de Mesclagem. So a facilidade de criacao de ramos nao seria suficiente se nao fosse o rastreamento automatico usado pelos DVCS, que torna o processo de mesclagem muito mais simples e indolor. Observacao: No Subversion, o rastreamento automatico de merges comecou a partir da versao 1.5Do ponto de vista da gerencia/coordenacaoParte das decisoes gerenciais envolve manter livre o caminho da equipe para que possam trabalhar da melhor maneira possivel. Outras decisoes importantes sao sobre reducao de custos. Nestes dois casos especificos, o modelo distribuido oferece as seguintes vantagens:Confiabilidade. No sistema centralizado, uma pane no servidor interrompe todo o desenvolvimento. Ja no sistema distribuido, alem de a equipe poder continuar seu trabalho (observacao: veja a secao controle de mudanca ainda e centralizado mais abaixo), os repositorios dos desenvolvedores funcionam como copias de backup de todo o projeto.Reducao de custos com servidor. A carga de processamento fica distribuida nas proprias maquinas dos desenvolvedores. O repositorio central, quando existe, tem o papel do repositorio oficial e nao como processador central das requisicoes.Em que situacoes o controle de versao distribuido nao vai tao bem?Nem tudo sao flores com o modelo distribuido de controle de versao.Maior complexidadeNo centralizado, os desenvolvedores trabalham no mesmo ramo, seja esse ramo o principal ou um ramo de manutencao.Essa forma de trabalho e mais simples de se entender. Mesmo que limitadamente, uma pessoa com pouco conhecimento de controle de versao consegue trabalhar com o resto da equipe.O modelo distribuido e mais complicado. A arquitetura peer-to-peer, ramos privados e as mesclagens aparentemente desordenadas podem tornar o grafo da evolucao do projeto confuso a primeira vista.Ao contrario do centralizado, nao adianta so commit e update para funcionar no tranco. Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferencia, tambem de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos. So assim, o grafo acima deixa de ser apenas um emaranhado e passa a representar muito claramente o fluxo do trabalho.Travamento de arquivos binarios precisa ser centralizadoDiferentemente dos arquivos de texto, arquivos binarios possuem um formato interno que nao e baseado em linhas de texto e, por isso, nao podem ser mesclados automaticamente pelo controle de versao ou manualmente pelo desenvolvedor.Sendo assim, a edicao concorrente de arquivos binarios e problematica. Duas pessoas editando ao mesmo tempo uma figura, por exemplo, nao conseguirao mesclar as modificacoes depois e o trabalho de uma delas precisara ser refeito.Com arquivos binarios, a melhor solucao e usar o travamento, isto e, sinalizar que o arquivo esta travado para edicao e que ninguem mais deve edita-lo enquanto isso.O modelo puramente distribuido nao e adequado para lidar com travamento justamente por nao possuir um servidor central que possa controlar as travas de todos.Controle de mudanca ainda e centralizadoAs ferramentas de controle de mudanca (e.g. Trac, Redmine, Mantis, Bugzilla) ainda nao acompanharam as de controle de versao na arquitetura peer-to-peer. Isto significa que mesmo usando um DVCS, ainda havera