Artigo publicado na MSDN Magazine 12 - A Arte de Versionar

Nesta segunda parte pretendo familiarizá-lo com a ferramenta Visual SourceSafe (VSS) e sua integração com o Visual Studio .NET. Na primeira parte, você compreendeu os problemas ocasionados pela ausência de controle de versão, aprendeu os conceitos básicos do VSS, como implantar a ferramenta e como estruturar seus projetos e soluções no VS.NET para permitir uma integração eficiente com o VSS. Agora apresentarei como proceder em cada cenário de utilização do VS.NET integrado ao VSS, além de identificar as boas práticas de um processo de desenvolvimento submetido à Gerência de Configuração.

Cenários de Utilização do VSS

Você irá interagir com o VSS de diferentes maneiras, dependendo da etapa de desenvolvimento do seu projeto. Para acompanhá-las, é necessário que você já possua o cliente do VSS instalado e integrado ao VS.NET. Suponha que você tenha criado uma solução no VS.NET (DemoVSS), formada por três projetos: uma class library (MyClassLibrary), uma aplicação ASP.NET (MyWebApp) e uma aplicação Windows (MyWindowsApp).

Observação: você não deve criar um novo projeto a partir da cópia e renomeação de um projeto antigo. Cada projeto possui um identificador global único (GUID), podendo haver problemas caso o projeto antigo e o novo sejam incluídos na mesma solução.

Criando e adicionando uma nova solução ao VSS

Vamos submeter a solução e os projetos criados ao controle de versão do VSS. Apenas relembrando, não é necessário (nem recomendado) abandonar o VS.NET para interagir com o VSS, visto que a integração entre as ferramentas disponibiliza no próprio VS.NET todas as interfaces de que você irá precisar.

Observe que, após a instalação do VSS, o menu File do VS.NET apresenta um novo item: Source Control., onde permite acessar um submenu que contém todos os comandos necessários para sua interação com o VSS. Muitos deles, entretanto, estão desabilitados, pois sua solução ainda não está submetida ao controle de versão. Para fazer isso, clique em Add Solution To Source Control... (opção que também pode ser acessada clicando-se com o botão direito na solução, através do Solution Explorer). Como nossa solução possui uma aplicação Web, o aviso exibido na Figura 1 aparecerá, referindo-se aos modos de acesso do VS.NET a projetos Web. Você pode ignorá-lo, marcando a opção Don't show this dialog box again e clicando em Continue.

Em seguida, a tela de logon do VSS surgirá, conforme a Figura 2. Digite suas credenciais e, a partir do botão Browse, localize o arquivo srcsafe.ini que deve estar em um compartilhamento no servidor em que foi instalada a base VSS. Em seguida, clique em OK na tela de logon e observe que uma nova janela surgirá, agora perguntando sobre a localização na base VSS em que sua solução será adicionada.

Essa localização geralmente depende de como está estruturado o repositório de sua organização. Por exemplo, é possível que exista um diretório na base VSS para cada cliente de sua organização, havendo subdiretórios para cada solução ou produto desenvolvido para o cliente. Por simplicidade, vou considerar que o repositório em que irei adicionar a solução contém apenas um diretório (MinhasSolucoes), conforme a Figura 3.

Existe uma infeliz coincidência de nomenclatura entre o VSS e o VS.NET: observe a existência de um campo chamado Project na figura anterior. Este campo não tem nenhuma relação com projetos do VS.NET, e sim com “projetos do VSS”, que você pode entender como um diretório qualquer no VSS. O que você digitar no campo Project da Figura 3 será o subdiretório (do diretório selecionado na árvore abaixo do campo) no qual será adicionada à solução, sendo: $/MinhasSolucoes/DemoVSS.root.

A solução agora está sob controle de versão. Ela foi transferida para a base VSS do servidor e os arquivos na sua máquina local nada mais são do que uma cópia somente leitura, o que está indicado pelos cadeados azuis que aparecem ao lado de cada item da solução no Solution Explorer (Figura 4).

Para obter permissão de escrita e editar um item da solução, é necessário efetuar o check out do mesmo. Você pode fazer isso através do menu File / Source Control / Check Out <nome do item>, ou então clicando com o botão direito no item no Solution Explorer e selecionando a opção Check Out. De todo modo, o VS.NET identifica automaticamente quando você está querendo editar um item não-checado, oferecendo a você a opção de checá-lo.

Independente do mecanismo que você utilizar para checar um item, o diálogo da Figura 5 será exibido. O campo Comments permite que você especifique o motivo pelo qual está checando o arquivo. Após checar um item, o cadeado azul não mais aparecerá ao lado dele no Solution Explorer, dando lugar a um outro símbolo indicando que o item agora está disponível para edição. Nunca é demais lembrar que, por padrão, nenhum outro desenvolvedor poderá checar um arquivo que já esteja checado por você.

Além de lhe garantir o controle exclusivo de um item, o VS.NET também atualiza, após o check out, sua cópia local do item, garantindo que a versão na qual você irá trabalhar é a mais atual. Desse modo, é possível que você perceba diferenças em um arquivo após checá-lo.

Checar um item não é a única maneira de obter sua versão mais recente. Se você clicar com o botão direito em um arquivo, solução ou projeto do Solution Explorer, irá encontrar o comando Get Latest Version. Para projetos e soluções, o nome desse comando será acompanhado do texto “(Recursive)”, indicando que você irá obter a versão mais recente de todos os itens que compõem a solução ou o projeto, não apenas o arquivo .sln ou .csproj. Após executar esse comando, o VS.NET consulta a base VSS para identificar se algum item foi modificado. Caso sim, a versão mais recente desse item é copiada para sua máquina local, embora não lhe garanta direitos de edição como é feito no check out.

Executar regularmente Get Latest Version é uma boa prática de controle de versão. Isto garante a sincronia entre sua cópia local e a versão na base VSS. Pela mesma razão, é recomendado que você não permaneça muito tempo com um arquivo checado. Uma vez que você tenha executado e testado localmente as mudanças necessárias em um arquivo, é hora de atualizá-lo na base VSS. Este processo, conhecido como check in, é feito de maneira análoga ao check out: selecione o item (ou os itens) no Solution Explorer e execute o comando Check In, que pode ser acessado tanto a partir do menu File / Source Control como do menu de contexto do item, através do clique com o botão direito.

Logo antes da execução do check in em um item, é uma boa prática executar um Get Latest Version dos demais itens da solução, compilá-los e testá-los com sua mudança local. Por exemplo, suponha que você checou e finalizou algumas alterações no arquivo Class1.cs do projeto MyClassLibrary. Clique com o botão direito na solução e execute Get Latest Version. O aviso da Figura 6 aparecerá, indicando que a versão local de Class1.cs está checada por você e questionando o que você quer fazer com ela. Marque o checkbox Apply to all items e clique em Leave. Desse modo, o VS.NET irá atualizar com a versão da base VSS todos os arquivos de sua cópia local, à exceção dos arquivos que estão checados por você. Isso permite que você possa testar suas mudanças locais com a versão mais recente da solução, minimizando a possibilidade de que erros de compilação e execução sejam inseridos na base VSS após o check in.

Outra dica interessante diz respeito ao cenário em que você precisa realizar mudanças muito demoradas (possivelmente dias) em um arquivo. Cada vez que você completar uma parte significativa da mudança no arquivo, que deve estar compilando e passando sem problemas em seus testes de unidade, recomenda-se que você execute check in (mesmo que ainda não tenha realizado a mudança completamente) e mantenha o arquivo checado, através de uma opção especial do diálogo de check in, exibida na Figura 7. Desse modo, você não perde o controle de edição do arquivo e permite que a base VSS esteja atualizada na medida do possível. Entretanto, jamais execute check in em itens instáveis, isto é, que apresentam erros de compilação ou que não passaram em seus testes de unidade. Isto pode provocar a “quebra do build”, comprometendo o andamento do projeto e o trabalho dos demais desenvolvedores.

Obtendo uma solução já existente pela primeira vez

Neste cenário, um outro desenvolvedor criou uma solução, já a adicionou à base VSS e você está, pela primeira vez, obtendo a solução da base VSS para a criação de uma cópia local.

Inicie o VS.NET e acesse a opção Open From Source Control, disponível a partir do menu File / Source Control. A tela de login do VSS surgirá (Figura 2), sendo necessário que você entre com suas credenciais e especifique a base VSS na qual está localizada a solução que se deseja acessar. Uma vez autenticado na base VSS, você poderá navegar pela estrutura de diretórios do repositório (Figura 8), devendo localizar o subdiretório em que está localizado o arquivo .sln da solução. No campo Create a new project in the folder, você poderá especificar o diretório que abrigará a solução e seus projetos em sua máquina local. Mais uma vez, não se deixe confundir pelo termo “project” desse campo, que não se refere a projetos VS.NET.

Após clicar em OK, será verificado se o diretório local especificado por você existe. Caso não, o VS.NET perguntará se você deseja criá-lo. Clique em Yes to All para permitir a criação do diretório da solução e dos subdiretórios de todos os projetos que não são aplicações Web. Para projetos Web, o diálogo Set Project Location surgirá, conforme a Figura 9. Observe que o VS.NET sugere, por padrão, o diretório virtual http://localhost/<Nome do Projeto Web> para a localização de projetos desse tipo. De modo a manter uma estrutura hierárquica e organizada de diretórios para soluções e projetos do VS.NET, como explicado na primeira parte deste artigo, recomenda-se que você utilize o Windows Explorer para criar um subdiretório no diretório local em que será armazenada a solução. É neste subdiretório em que estará localizado o projeto Web, sendo necessário, através do IIS ou do próprio Windows Explorer, transformá-lo em um diretório virtual. Uma vez feito isso, volte ao diálogo Set Project Location (Figura 9), certifique-se de que o diretório virtual especificado é o que você criou e só então clique em OK. Após os projetos serem copiados localmente, observe o cadeado azul ao lado de cada item no Solution Explorer (Figura 4), indicando que eles não estão disponíveis para edição a não ser que você execute check out dos mesmos.

Obtendo uma solução já existente em vezes subseqüentes

Para trabalhar em uma solução, sujeita ao controle de versão, de que você já possui uma cópia local (cenário anterior já executado), você não deve executar o comando Open From Source Control. Através do comando File / Open Solution do VS.NET, localize o arquivo .sln da solução que está em sua máquina local. Após o VS.NET ter aberto a solução e seus projetos, clique com o botão direito na solução no Solution Explorer e execute o comando Get Latest Version (Recursive), para garantir que sua cópia local seja atualizada com a versão mais recente da base VSS. Caso você possua arquivos checados, o aviso da Figura 6 surgirá, sendo necessário a você repetir o procedimento já explicado anteriormente.

Adição de novos arquivos e projetos na solução

Caso novos projetos tenham sido adicionados à solução por outro desenvolvedor, o VS.NET lhe informará disso quando você executar Get Latest Version, permitindo que sua cópia local seja atualizada. Caso novos arquivos tenham sido adicionados a um projeto, por sua vez, eles simplesmente serão adicionados à sua cópia local na próxima execução de Get Latest Version, não havendo, neste caso, nenhum alerta do VS.NET.

Para adicionar/renomear/deletar um item de um projeto do VS.NET, é necessário o check out no arquivo do projeto. Recomendo que você tente adicionar o arquivo normalmente, sem se preocupar com isso. Quando alguma coisa precisar ser checada, o VS.NET informará para você.

Analogamente, para adicionar/renomear/deletar um projeto de uma solução sujeita ao controle de versão, é necessário o check out do arquivo da solução, também indicado automaticamente pelo VS.NET. É importante observar que outros desenvolvedores não vão poder enxergar o novo projeto até que você execute o check in do mesmo.

Histórico de Arquivos

O VSS mantém um histórico contendo a evolução de um arquivo, desde o momento em que ele foi submetido pela primeira ao controle de versão. Cada vez que um arquivo sofre check in, uma nova entrada é adicionada ao histórico do arquivo no VSS. Para visualizar esse histórico, selecione o arquivo desejado no Solution Explorer e acesse o menu File / Source Control / History. O diálogo History Options aparecerá, conforme a Figura 10.

Como explicado na primeira parte deste artigo, gerentes de configuração podem aplicar labels (rótulos) a um arquivo ou conjunto de arquivos da base VSS, de modo a poder recuperar, no futuro, a versão dos arquivos que corresponde ao label, mesmo que eles tenham sido modificados. Por exemplo, é comum rotular arquivos quando um build ou release interno foi concluído. Através da History Options, você pode informar se deseja ou não que labels apareçam no histórico a ser exibido, através do checkbox Include Labels. É possível, inclusive, obter apenas as versões que foram rotuladas, clicando em Labels Only.

Os campos From e To permitem uma pesquisa mais refinada. Esses campos podem conter datas ou horas, acompanhados do prefixo “D” (por exemplo, D01/02/04;13:15). Você também pode informar labels nesses campos, acompanhados do prefixo “L” (por exemplo, LMeuLabel). Alternativamente, você pode utilizar os campos From e To para informar diretamente uma faixa de versões que se deseja obter. Por exemplo, o valor 3 para o campo From e o valor 7 para o campo To fará com que as versões de número 3 a 7 sejam exibidas no histórico. (Observação: cada check in incrementa em um o número da versão do arquivo na base VSS.) Por fim, o campo User permite que você visualize apenas as versões correspondentes a um usuário específico. Após clicar em OK, o histórico do arquivo finalmente será exibido, conforme a Figura 11. Se você clicar em Details, poderá ver os comentários informados pelo desenvolvedor quando ele realizou o check in correspondente à versão selecionada. O botão Get, por sua vez, permite que uma versão específica seja copiada para a máquina local.

Visualizando Diferenças entre Versões

É sempre útil obter de maneira ágil as diferenças entre duas versões distintas de um arquivo. Se você possui uma janela de histórico aberta (Figura 11) mostrando mais de uma versão, você pode selecionar duas versões e então clicar no botão Diff, fazendo com que o diálogo Difference Options seja exibido, conforme a Figura 12. (Alternativamente, você pode clicar em File / Source Control / Compare Versions.)

Ao clicar em Browse..., você poderá navegar por pastas do Windows ou por diretórios do SourceSafe, à procura das versões a serem comparadas. Em relação ao modo como as diferenças serão exibidas, existem três possibilidades. O formato Unix apresenta as mudanças da mesma maneira que o utilitário diff, do Unix. O formato SourceSafe apresenta um formato do próprio VSS para visualização das diferenças. Entretanto, recomendo a utilização do formato Visual, por sua simplicidade. Ele apresenta as duas versões em comparação lado a lado, colorindo as diferenças, conforme a Figura 13.

Trabalhando no Modo Desconectado

O VS.NET e o VSS também permitem que você trabalhe offline, isto é, apenas com sua cópia local, de maneira desconectada da base VSS. Isso pode ser útil caso você precise desenvolver sem acesso ao repositório, como em um laptop durante uma viagem, por exemplo. Para trabalhar desconectado, acesse o menu File / Change Source Control, que abrirá o diálogo da Figura 14.

Para se desconectar da base VSS, selecione os projetos desejados e clique no botão Disconnect. Quando você tentar executar o check out de um arquivo, receberá uma mensagem informando-o de que você está trabalhando em modo desconectado e que dados podem ser perdidos no futuro caso cuidados não sejam tomados. Clique em Check Out (disconnected) para proceder com o check out no modo desconectado.

Quando você estiver pronto para reconectar (você retornou ao escritório, por exemplo), abra novamente o diálogo da Figura 14 (File / Change Source Control). Clique no botão Connect para se reconectar à base VSS. O VS.NET, tentará executar o check out real dos arquivos alterados por você enquanto desconectado. Você não deve permitir que o VS.NET substitua a cópia local dos arquivos que foram checados no modo desconectado pela cópia atual da base VSS. Para isso, clique em Leave this file quando perguntado. Nunca é demais lembrar que deve haver planejamento e sincronia entre os desenvolvedores na medida de possível, de modo a evitar check outs indevidos e desperdício de trabalho.

Trabalhando com Múltiplos Check Outs

O administrador do VSS pode permitir que um mesmo arquivo seja checado por mais de um desenvolvedor. Para isso, ele deve acessar o módulo administrativo do VSS e acessar o menu Tools / Options / guia General / Allow multiple checkouts. Múltiplos check outs funcionarão apenas para arquivos texto. Para arquivos binários, um desenvolvedor continua detendo o controle exclusivo sobre o arquivo após executar check out. Apesar de possível, recomenda-se não efetuar múltiplos check outs em arquivos de projeto ou de solução, devendo essa funcionalidade ser aplicada apenas para arquivos de código-fonte (.cs, .vb, etc.).

Com a opção de múltiplos check outs habilitada, o VSS apresenta um aviso (e não mais uma proibição) toda vez que você efetuar check out em um arquivo já checado por outro desenvolvedor. Clique em Yes para confirmar que você deseja efetuar o check out mesmo assim.

Você já aprendeu que deve executar Get Latest Version da solução antes de efetuar o check in de um arquivo, clicando em Leave quando perguntado sobre o que fazer com sua versão local em comparação com a versão da base VSS (Figura 6). No caso de múltiplos check outs habilitados, entretanto, você não deve mais clicar em Leave, e sim em Merge. Isto fará com que o VSS realize automaticamente uma fusão entre sua versão local e a versão na base VSS (que já poderia estar atualizada por outro desenvolvedor). Caso conflitos sejam encontrados entre as versões (por exemplo, uma mesma linha foi alterada nas duas versões), o VS.NET abrirá uma tela de diálogo semelhante à exibida na Figura 13 para que você possa, visualmente, escolher que alteração deseja persistir.

Conclusão

Neste artigo, você pôde praticar os conceitos mais comuns de controle de versão através da integração do Visual Studio .NET com o Visual SourceSafe. Você compreendeu como agir nos diferentes cenários de utilização do VS.NET integrado ao VSS, além de aprender como visualizar o histórico de arquivos, como conferir as mudanças entre diferentes versões de um mesmo arquivo, como trabalhar no modo desconectado e como lidar com múltiplos check outs.

Muito se tem perguntado sobre o futuro do Visual SourceSafe com o surgimento do Visual Studio Team System (VSTS), a nova plataforma de ferramentas da Microsoft, que cobre de maneira mais completa o ciclo de vida de projetos de software e que inclui, entre outros componentes, o Visual Studio Team Foundation, responsável pelo controle de versão assim como o VSS.

A boa notícia é que o VSS não deixará de existir por causa do VSTS. Na verdade, os dois possuem nichos distintos. Enquanto o VSTS é aplicável em organizações maiores, que necessitam de soluções definitivamente mais complexas para gerência de configuração, o VSS foca em times menores (inclusive desenvolvedores individuais) que necessitem de uma ferramenta mais leve e prática apenas para usufruir, de maneira simples e produtiva, os benefícios do controle de versão. É aguardado, inclusive, o lançamento do Visual SourceSafe 2005, que se integrará ao VS.NET 2005 e, entre outras novas funcionalidades, permitirá acesso remoto pela Web via HTTP. Esse, entretanto, é assunto para um outro artigo.

• A opção File / Source Control, que aparece no VS.NET após a instalação do VSS, expõe todos os comandos necessários para o controle de versão.
• Executar regularmente Get Latest Version é uma boa prática de controle de versão. Isto garante a sincronia entre sua cópia local e a versão na base VSS. Pela mesma razão, é recomendado que você não permaneça muito tempo com um arquivo checado.
• Logo antes da execução do check in em um item, é uma boa prática executar um Get Latest Version dos demais itens da solução, compilá-los e testá-los com sua mudança local.
• Jamais execute check in em itens instáveis, isto é, que apresentam erros de compilação ou que não passaram em seus testes de unidade.
• Quando alguma coisa precisar ser checada, o VS.NET automaticamente informará para você.

Referências:

• Team Development with Visual Studio .NET and Visual SourceSafe
• Visual SourceSafe Roadmap
• Mastering Visual Studio .NET (Ian Griffiths, Jon Flanders & Chris Sel - Ed. O'Reilly)