Usando Subversion com Visual Basic 6

Question

Minha equipe está migrando do Visual SourceSafe para o Subversion em breve, enquanto desenvolve/suporta um projeto legado no Visual Basic 6.0, então tenho algumas perguntas:

• Qual é a melhor ferramenta para integração do Subversion IDE no Visual Studio 6?(ou não vale a pena...)
• Existem práticas recomendadas para usar o Subversion com Visual Basic 6.0?(tipos de arquivo a serem ignorados, etc.)

Answer 1

Eu concordaria que o Tortoise SVN no Windows Explorer seria a melhor maneira de usar o SVN com VB6.

A maior mudança que você encontrará ao migrar para o SVN é a ideia de "Check out" e "Check in" não serem exatamente iguais a "Update" e "Commit"...portanto, qualquer integração IDE com VB6 é limitada porque o VB6 suporta MSSCCI, um mecanismo de check-out/check-in.Certa vez, usei o TamTam SVN (http://www.daveswebsite.com/software/tamtamsvn/index.shtml) com o Visual Studio 2003, mas parei porque achei isso limitante.Mesclar/ramificar/culpar, etc.são recursos muito poderosos que o Tortoise SVN fornece que não estavam no TamTam.Tigre também tem http://svnvb6.tigris.org/, mas eu não tentei.

Novamente, embora você provavelmente consiga um IDE para trabalhar com VB6, eu não o recomendaria, pois o maior ponto forte da migração para o SVN é quebrar a filosofia Source Safe de check-in/check-out.

Answer 2

Como o Subversion usa um ciclo de atualização/edição/commit (em vez de checkin/checkout), você precisará ter cuidado especial com arquivos binários.A maioria dos formulários em VB6 consiste em dois arquivos:MeuForm.frm e MeuForm.frx.Os arquivos *.frx são binários e, portanto, não podem ser mesclados.

Dado isso, eu configuraria o Subversion para exigir "bloqueio" em arquivos .frx.Isso significa que apenas uma pessoa pode fazer check-out do arquivo por vez.Ao fazer isso, você garantirá que apenas um desenvolvedor possa modificar esses arquivos por vez, e sempre ficará claro quem é essa pessoa no momento.Se você não fizer isso, estará se preparando para grandes dores de cabeça.

Answer 3

Tipos de arquivos a serem ignorados:

*.vbw
Arquivo de espaço de trabalho que é gerado automaticamente quando você fecha um projeto e contém quais arquivos você abriu, etc.

MSSCCPRJ.SCC
O arquivo de status de controle de origem gerado pelo IDE VB6 (se você optar pela solução de controlar SVN no Windows Explorer, deverá desabilitar o plugin de controle de origem em VB6 e isso não será gerado).

*.log
Estes são arquivos gerados se algo der errado ao carregar uma GUI de formulário.O arquivo está localizado no mesmo local que o arquivo de formulário com nome igual ao arquivo de formulário.
Exemplo: MyForm.frm gera MyForm.log.

É claro que você só deve fazer isso se não tiver os arquivos de log necessários no controle de origem ...

Answer 4

Dependendo de quanto você planeja fazer nesses projetos legados, consideraria não mudar.

Eu realmente aconselho você a mudar para o SVN.Conheço alguns projetos que perderam o código-fonte porque o banco de dados VSS foi corrompido.

Acho que existem ferramentas que realizam a migração do SourceSafe para o SVN.(Sim - uma rápida pesquisa no Google confirmou isso.) Dessa forma, você não perderia o histórico de revisões.

Answer 5

Meu palpite seria não se preocupar com a integração e apenas usar o Tortoise SVN no Windows Explorer.

Quanto aos tipos de arquivo a serem ignorados, faça um teste, verifique, construa e veja se algum arquivo foi alterado (para o Visual Studio moderno, tenho tendência a ignorar os arquivos .suo)

Answer 6

Para o lado do servidor, VisualSVN Server, é uma solução super simples, estamos rodando em um vmware virtual, e está funcionando bem.

Se você é um cara de linha de comando, eu realmente gosto da interface de linha de comando do svn, acho menos confuso chegar a certas ações do que o tortoise, como o status da pasta.Mas se você é fã de exploradores, a tartaruga é mais que adequada, vindo de um mundo de origem segura.

As principais coisas a ignorar são:

• Artefatos reproduzíveis (dll, pdb, exe)
• Configurações específicas do ambiente (ou seja,o arquivo de configurações para vs, arquivo csproj.user, arquivos .suo)

Answer 7

Dependendo de quanto você planeja fazer nesses projetos legados, consideraria não mudar.

Ao vasculhar o código legado, realmente ajuda ter todo o histórico e culpa.O SVN é muito melhor que o VSS, mas você perderá o histórico ao mudar.

Se você pretende desenvolver muito o VB6, então pode valer a pena mudar para o SVN, mas se você vai fazer tanto daqui para frente, também vale a pena revisar o projeto?

Estou com um problema parecido, só que os projetos legados estão em Delphi.Se eles estivessem no VB6, acho que consideraria 'atualizá-los' para o VB.Net, apenas por questão de manutenção.