Escolha e configuração do controle de versão

4

Alguém? Essa pergunta também pode ter sido melhor em SO. Então, qualquer um com a habilidade para fazê-lo, sinta-se à vontade para esbarrar nele.

Estou prestes a configurar um novo laptop e no processo de transição para um novo sistema de controle de versão como parte de uma limpeza geral. Atualmente eu uso um sistema de controle de versão centralizado (sim, é é VSS, e sim eu conheço todos os prós e contras desse sistema, mas como um sistema de usuário único funciona bem para mim). Eu tenho muito poucas exigências para um novo sistema e estou livre para escolher entre qualquer um dos atuais players mainstream, mas as restrições de custo me empurrarão para oss. Alguns dos meus requisitos são:

  • É executado em uma única máquina (ou seja, o laptop em questão) nas janelas
  • Não estou compartilhando coisas com outros desenvolvedores ou funcionários - isso é mais para meus próprios benefícios históricos.
  • Eu quero o código fonte da versão, documentação e arquivos binários
  • Eu tenho uma grande hierarquia de projetos que não estão relacionados (veja abaixo)
  • Eu tenho arquivos dentro da hierarquia que não precisam ser controlados (mas poderiam ser)
  • Alguns projetos usam o Visual Studio, portanto, alguma integração pode ser interessante.
  • Pode haver algum compartilhamento de arquivos entre trabalhos.
  • Eu geralmente só preciso de um pouco de ramificação em arquivos de código

A hierarquia de diretórios que tenho no momento é um pouco como:

Root
 |
 |--Customer #1
 |    |
 |    |--Job #1
 |    |    |
 |    |    |--Data files received from Customer for Job (not controlled)
 |    |    |--Documentation files (controlled)
 |    |    |--Project information files (not controlled - but could be) 
 |    |    |--Software Project Files (controlled)
 |    |    |--Scratch dir for job (not controlled)
 |    |    
 |    |--Job #2
 |         | (same structure as above)
 |
 |--Customer #2
 |    |..
 |
 |--Cusmtomer #n
      |..

Atualmente, tenho cerca de 22 clientes com números diferentes de projetos abaixo deles.

No momento, tenho um único repositório VSS com base na raiz da estrutura de diretórios. Se eu mantivesse um sistema centralizado (ou seja, SVN), acredito que deveria manter a mesma abordagem e continuar com um único repositório baseado no diretório raiz. Esta é uma abordagem válida?

No entanto, se eu mudar para uma ferramenta distribuída, não tenho certeza de como lidar com a situação. Meu palpite inicial é que eu não deveria ter um repositório baseado na raiz da minha estrutura de diretórios inteira - mas isso é um palpite, então eu realmente não sei como é válido.

Devo lançar uma abordagem distribuída no nível do diretório Raiz, Cliente, Tarefa ou subemprego?

Além disso, o que não estou claro sobre as ferramentas distribuídas (e talvez com o SVN também) é se posso ramificar partes de um repositório. Por exemplo, posso ver o código-fonte de ramificação em projetos de software como sendo útil, mas ramificando minha documentação como não sendo útil. Então, se eu lançar um repositório no nível do trabalho, posso apenas ramificar os arquivos de projeto de software? Ou todos os arquivos desse trabalho seriam ramificados?

Toda vez que olho para ferramentas distribuídas, fico com uma sensação incômoda de que elas não são adequadas ao meu estilo de configuração. Sinto-me incomodado com a idéia de ter que configurar manualmente algo como 50 a 80 repositórios separados (se eu usar o nível do trabalho, ou 20+ se estiver no nível do cliente) dentro da minha hierarquia de diretórios. Esse sentimento também se estende a ter todos esses repositórios espalhados também - no entanto, eu tenho uma estratégia de backup que eu confio, então este último sentimento é muito bem infundado.

Então, que conselho você pode me dar? Obrigado antecipadamente!

    
por Peter M 24.05.2010 / 02:41

3 respostas

1

Eu estou usando o TortoiseSVN para mim com grande sucesso. Configurar um repositório (baseado em arquivo) é realmente fácil usando um novo diretório em branco e a opção 'criar repositório aqui'. O TortoiseSVN parece manipular todo o trabalho necessário para trabalhar com o repositório, portanto, nenhuma instalação extra é necessária.

    
por 26.05.2010 / 19:32
0

Eu uso principalmente o Subversion, e atualmente só sei um pouco sobre sistemas distribuídos, então falarei da perspectiva do SVN.

Se apenas você estiver usando o controle de origem, em uma máquina, as vantagens do controle de origem distribuído, bem distribuído, serão reduzidas.

O Subversion é um pouco difícil de configurar se feito manualmente. No entanto, existe um pacote (gratuito) chamado VisualSVN que faz o trabalho para você, então você pode apenas usar o SVN, e não precisa se preocupar com configuração ou configuração.

Se você estiver interessado na integração do Visual Studio para SVN, há alguns plugins que eu conheço: AnkhSVN (gratuito) e VisualSVN (pago). O último é da mesma empresa que produz o pacote de instalação gratuito do VisualSVN mencionado acima.

No que diz respeito à manipulação de vários clientes, cada um com projetos, você poderia usar um único repositório global contendo tudo. Outra ideia pode ser criar um repositório separado para cada cliente, cada um contendo projetos para esse cliente. Você teria um pouco mais de controle sobre cada repositório dessa maneira, mas haverá um pouco mais de sobrecarga para você.

Você menciona projetos de ramificação. O SVN faz ramificações no nível do repositório, você não pode ramificar apenas um subconjunto específico. Isso favoreceria a ideia de repositório por cliente mencionada acima. No entanto, no SVN, as ramificações e tags são baratas, já que armazenam changesets (deltas), não cópias completas. Ferramentas distribuídas como Git e Mercurial são otimizadas para ramificação e fusão, então a experiência pode ser melhor com elas - eu não sei o suficiente sobre elas para dizer com certeza.

Espero que ajude.

    
por 26.05.2010 / 19:28
0

Eu tive sorte com o Mercurial , usando o TortoiseHg para o Windows. É um vcs distribuído, mas os recursos distribuídos não atrapalham o uso como usuário único. Eu usei para a história pessoal e alguns projetos de programação e funcionou bem. A instalação foi muito fácil, menos complicada do que o SVN, se bem me lembro, e foi muito fácil fazer e sincronizar backups de todo o meu repositório.

    
por 26.05.2010 / 20:30