Sistema de controle de versão em projetos web

O desenvolvimento de software é quase sempre realizado em equipe e controlar as alterações de cada desenvolvedor de forma que se mantenha a integridade do código fonte do software é uma necessidade recorrente. Por isso, o uso de uma ferramenta que permita o controle de versão de forma que múltiplos usuários possam realizar alterações de forma concorrente pode trazer melhorias no processo de desenvolvimento.

Um sistema de versões concorrente (CVS na sigla em inglês) é uma ferramenta para gerenciar o desenvolvimento de software colaborativo que permite que um grupo de desenvolvedores trabalhe no mesmo conjunto de arquivos fontes de forma que as alterações sejam integradas e persistidas em um repositório que guarde todas essas alterações. O uso de uma ferramenta CVS tona-se imprescindível para que o controle adequado da evolução do software seja atendido e que a produtividade melhore, deixando o desenvolvedor focado em solucionar problemas relativos ao domínio do desenvolvimento ao invés de ter que se preocupar com o estado de cada arquivo que integra a solução do projeto.

O uso de ferramentas que permitem esse controle vem se tornando uma prática comum na indústria e em projetos de software livre, mas ferramentas para uso em ambientes integrados de desenvolvimento (IDE, na sigla em inglês) ainda não funcionam de forma harmônica dependendo da plataforma de desenvolvimento e da IDE utilizada. Neste artigo analisaremos o emprego de um sistema de versionamento integrado a uma IDE de mercado no desenvolvimento de aplicações web. Apresentaremos um estudo de caso demonstrando as ferramentas disponíveis para essa integração, o uso, os benefícios e as eventuais limitações dessa integração e o que pode ser aprimorado na ferramenta utilizada.

Sistemas de controle de versão

O trabalho em equipe em um projeto de software requer um processo de gerenciamento dos recursos, pessoas, tempo, requisitos e entregas. Não é diferente com o código fonte de um software que está sendo desenvolvido ou mantido. Apesar de este ser mais um aspecto que precisa ser gerenciado durante o ciclo de desenvolvimento, ele tem algumas características muito particulares. Diferente das pessoas, requisitos e entregas, o código fonte de um software sofre inúmeras alterações, todos os dias durante o processo de desenvolvimento. Dependendo do tamanho da equipe, o volume de alterações pode chegar à casa do milhar. Além do grande volume, essas alterações precisam ser passíveis de serem revertidas e integradas, de forma harmônica e garantindo a integridade do código. Fazer tudo isso de forma manual é um processo árduo, que normalmente gera erros e muitas vezes torna-se impossível se a equipe estiver distribuída e for muito grande ou o volume de alterações for significativo. Nesses casos, o mais indicado é que seja utilizada alguma ferramenta que permita esse gerenciamento de forma automatizada.

A maior parte dos projetos de software envolvem diferentes desenvolvedores trabalhando concorrentemente em uma variedade de grupos de arquivos, durante um longo período de tempo, e por isso é essencial que todas as alterações feitas pelos diferentes desenvolvedores sejam persistidas e rastreáveis, de forma que se tenha registro a respeito de quem fez o que e quando. A definição do responsável pela alteração permite a atribuição de responsabilidade assim como uma comunicação direta em caso de dúvidas quanto à mesma. Mais importante ainda do que controlar quem fez o que é poder integrar as diversas modificações em um só resultado, de forma que a colaboração seja efetivamente construtiva com o objetivo de um resultado final comum, e não resultados incompletos paralelos.

O Sistema de Controle de versão CVS (na sigla em inglês para Concurrent Version System) foi originalmente desenvolvido por Dick Grune em 1984 como o primeiro CVS a suportar o gerenciamento de múltiplos arquivos e tornado público em 1986 e é dele que os sistemas de controle de versão atuais derivam.

As funcionalidades básicas de um sistema de controle de versão (CVS) são manter o histórico e os respectivos estados das alterações realizadas nos arquivos ao longo do tempo e integrar as contribuições dos diferentes desenvolvedores que atuam no projeto. Esse conjunto de histórico e estado dos arquivos é mantido em um diretório estruturado pelo servidor do CVS como repositório, desempenhando o servidor CVS um papel central e permitindo que os desenvolvedores trabalhem remotamente (seja na mesma rede local ou via internet) de forma colaborativa.

SVN Subversion

Apache Subversion (também conhecido como SVN) é um sistema de controle de versão de código aberto, criado em 2000 pela CollabNet e é atualmente um software mantido como um projeto da Apache Software Foundation. Foi desenvolvido para funcionar de forma similar ao CVS, mas corrigindo algumas falhas de seu antecessor e para prover algumas funcionalidades não existentes no CVS. O SVN é multiplataforma (tanto no que tange o servidor quanto os clientes) e pode ser usado por clientes com diferentes sistemas operacionais acessando um mesmo servidor que mantém o repositório.

O SVN é um sistema de versionamento flexível, que mantém o histórico mesmo após a ocorrência de eventos como mover, copiar ou renomear. Essas três características não estão presentes em muitos sistemas de controle de versão, mais notavelmente no CVS. Além disso, o SVN trabalha com o conceito e atomicidade nas operações, não permitindo operações parciais, que poderiam prejudicar a consistência do repositório.

A arquitetura proposta pelo SVN é semelhante à de um cliente-servidor, conforme ilustrado na Figura 1. No servidor temos os repositórios e os diversos clientes que acessam este repositório tanto para enviar quanto para receber atualizações. Cada usuário mantém uma cópia local do conjunto de arquivos que faz parte do projeto e sincroniza esses arquivos periodicamente com o servidor SVN. Do lado do servidor o administrador gerencia os repositórios e as permissões dos usuários de acordo com as necessidades do projeto. Já do lado do cliente o acesso ao repositório se dá por meio da configuração da localização do repositório, que pode ser um endereço local ou uma URL da internet, e da autenticação do usuário que recebeu previamente a permissão para acesso ao repositório, que pode ser só de leitura ou de leitura e escrita.

Figura 1. Diversos clientes acessam o mesmo repositório

A ferramenta utilizada pelo desenvolvedor para atuar como cliente funciona através de linhas de comandos e pode ter ainda uma interface gráfica que permita a integração com o explorador de sistema de arquivos do sistema operacional utilizado. Caso seja utilizado no projeto um ambiente de desenvolvimento integrado (IDE, na sigla em inglês), é possível ainda a integração entre o cliente SVN e essa ferramenta, seja através de plug-ins ou suporte nativo da ferramenta.

Cenário

Em empresas de pequeno porte que tem foco no desenvolvimento de projetos web é comum haver a divisão do projeto, na fase de implementação, em etapas que são comumente definidas como criação, montagem e desenvolvimento. Apesar de conceitualmente essas etapas seguirem um modelo em cascata, é recorrente a necessidade de retorno para fases anteriores quando se detecta falhas, quando há alterações de escopo ou quando é necessária uma integração entre duas ou mais etapas. Neste cenário, controlar as alterações e evoluções dos arquivos que fazem parte do projeto de forma manual é um trabalho árduo e complexo, e a falta de uma ferramenta apropriada tende a aumentar a necessidade de comunicação informal entre os envolvidos e causar a perda de parte dos trabalhos por falhas no processo de controle manual. Neste contexto, a utilização de um sistema de controle de versão tende a melhorar o processo de desenvolvimento e permitir uma gestão mais eficiente do código fonte do projeto.

Estudo de caso

Foi realizado um estudo de caso em uma agência web, especializada em projetos para internet e dispositivos móveis que atua com foco no desenvolvimento de sites, sistemas para internet, sistemas de gerenciamento de conteúdo e aplicativos móveis. Trata-se de uma empresa de pequeno porte, com dez anos no mercado e que atua tanto com foco em clientes do segmento privado quanto governo, sendo especializada na plataforma ASP.NET.

Este estudo de caso foi realizado no processo de desenvolvimento do sistema de gestão de conteúdo (CMS na sigla em inglês) de um grande cliente privado. No processo de desenvolvimento deste projeto atuaram cinco pessoas, incluindo analistas, líder de equipe, desenvolvedores de aplicação executada no servidor (back-end) e programadores de interface e interações com o navegador (front-end).

Ferramenta selecionada

Como o projeto objeto desse estudo de caso iria ser desenvolvido na plataforma ASP.NET e, por isso seria utilizada a IDE Visual Studio, realizou-se uma pesquisa para avaliar as diferentes possibilidades de integração entre essa IDE e um sistema de controle de versão. A IDE em questão tem suporte nativo (como cliente) ao sistema de controle de versão Team Foundation Version Control (TFVC), que assim como o Visual Studio, é desenvolvido pela Microsoft.

Para este projeto analisamos alguns sistemas de versionamento que poderiam ser utilizados. Existem várias opções, mas as ponderações foram feitas entre as seguintes soluções: Git, TFVC e SVN.

O TFVC foi descartado pelo fato de ser uma solução que consome muito recurso, já que está dentro do conceito de uma ferramenta para gerenciamento do ciclo de vida de uma aplicação (ALM, na sigla em inglês) e não somente para controle de versão. O objetivo neste projeto era integrar à IDE uma solução simples com foco em controle de versão. Por mais que a solução da TFVC ofereça mais recursos (além do controle de versão), esses recursos trazem complexidade e custos computacionais.

O Git, por sua vez, foi descartado por razões semelhantes à do TFVC. Apesar de o Git ser uma ferramenta focada especificamente no controle de versão, ela é mais complexa de operar. Os conceitos de repositório local e remoto e a ampla gama de funcionalidades via linha de comando trazem recursos muito úteis para uma equipe, mas é necessário um entendimento maior do processo de versionamento pelos envolvidos e no projeto em questão precisávamos de uma solução rápida e que exigisse o mínimo da equipe. Por essas razões e pela facilidade de configurar e instalar o ambiente (tanto no servidor quanto nos clientes), foi definido que seria utilizado o sistema de versionamento SVN Subversion através das ferramentas Visual SVN Server e o plug-in para o mesmo.

Configuração do ambiente

Para montar o ecossistema do SVN foi instalado o VisualSVN Server em um servidor Windows e dessa forma foi possível criar o repositório e vincular determinados usuários de rede ao repositório, definindo as permissões adequadas. A Figura 2 demonstra a tela inicial da aplicação instalada no servidor. A versão Standard Edition do VisualSVN Server é gratuita e pode ser utilizada para uso comercial. Praticamente não é necessário nenhum passo adicional além da instalação executada via assistente. Caso seja necessário o acesso através da internet ao repositório, é necessário realizar configurações específicas em relação ao servidor HTTP.

Figura 2. Interface visual de configuração e gestão do VisualSVN Server

Nos computadores dos desenvolvedores foi instalado o plug-in para Visual Studio 2012 de nome VisualSVN, que também é gratuito (desde que os computadores clientes não sejam membros de um diretório ativo). Tanto o plug-in quanto o servidor de controle de versão são desenvolvidos pela mesma empresa, e este foi um fator que permitiu uma integração harmônica. O plug-in se integrou totalmente à IDE e ficou evidente que todo o controle de versionamento e sincronização com o servidor central é feito diretamente na ferramenta de desenvolvimento, sem a necessidade do uso de linha de comando.

Utilização da ferramenta

É comum que no decorrer do desenvolvimento de software nos deparemos com alguns problemas como, por exemplo, o armazenamento de versões e o compartilhamento do código fonte para mais de um desenvolvedor. Ainda é possível encontrar empresas pequenas ou com equipes com pouca maturidade que utilizam o “versionamento” através de um processo manual e compartilhamento de uma pasta em rede. Essa prática implica em muita perda de trabalho, especialmente quando diversos desenvolvedores trabalham no mesmo projeto e é desaconselhada devido ao alto grau de dificuldade na classificação das versões e confusão na detecção de qual versão é a corrente, assim como na integração de versões quando há acesso concorrente no mesmo arquivo.

Com o uso do sistema de versionamento essas atividades de controle de versão são automatizadas e os principais comandos disponíveis para a rotina de versionamento no plugin são:

· Initial Commit (envio inicial): permite o envio de uma aplicação que esteja na máquina de um desenvolvedor para o repositório. Este comando é utilizado quando se inicia o uso do versionamento para uma aplicação. Pode ser utilizado tanto para aplicações já existentes (que passarão a ser versionadas) ou para aplicações cujo desenvolvimento está sendo iniciado;

· Update (Atualização): permite aos desenvolvedores que têm acesso ao repositório baixar a última versão da aplicação em desenvolvimento, conforme Figura 3 no item destacado número 1, e Figura 4 no item destacado número 3.

· Commit (Envio): permite aos desenvolvedores que têm permissão de escrita no repositório enviar a sua versão atual do software que está sendo desenvolvida, conforme Figura 3 no item destacado número 2 e Figura 4 no item destacado número 4;

· Get lock (bloquear): permite aos desenvolvedores com permissão de bloqueio/escrita bloquear um arquivo ou pasta de forma que outros desenvolvedores não possam editar esses itens enquanto o mesmo não for desbloqueado. Esta ação é executada através do comando release lock (desbloquear), conforme Figura 4 no item destacado número 6;

· Show log (mostrar histórico): permite aos desenvolvedores inspecionar o histórico de modificações de um arquivo ou pasta. Nesse histórico são mostradas as modificações realizadas ao longo do tempo, exibindo o autor, a mensagem de texto enviada pelo autor quando fez o commit, a data e o identificador numérico da revisão. Para cada item listado é possível ver mais detalhes sobre a modificação, que exibirá linha a linha o que foi modificado (incluindo alterações, adições e exclusões), conforme Figura 4 no item destacado número 5;

· Add to Subversion (adicionar ao subversion): permite incluir um arquivo ou pasta no versionamento. É possível que um projeto esteja versionado, mas que haja arquivos que fazem parte do projeto que não estejam incluídos no versionamento. Essa possibilidade existe porque pode haver alguns arquivos que não precisão ou não podem ser versionados e por isso não são incluídos no versionamento;

· Remove from Subversion (Remover do subversion): permite remover um arquivo ou pasta do versionamento. Este comando não excluirá o arquivo/pasta do projeto, mas o mesmo deixará de ser versionado.

Durante o processo de update ou commit pode ser detectado que um mesmo arquivo foi alterado por diferentes desenvolvedores. Se ao fazer um commit o SVN verificar que um ou mais arquivos que o desenvolvedor está tentando enviar foi alterado (e enviado ao repositório) depois que ele fez o último update, o SVN não permitirá o commit e solicitará que seja feito um update antes do commit.

Durante o processo de update, se for detectado que foram feitas alterações em partes diferentes dos arquivos que o desenvolvedor corrente alterou, o SVN irá fazer automaticamente um merge (junção) das alterações de forma que as alterações realizadas por diferentes desenvolvedores sejam integradas em um único arquivo. Caso alguma das alterações realizadas por diferentes desenvolvedores tenha ocorrido na mesma linha, o SVN irá informar ao desenvolvedor que ocorreu um conflito que não pode ser resolvido de forma automatizada. Caberá ao desenvolvedor decidir se sua cópia ou a do outro desenvolvedor será mantida como a principal.

Como em projetos web as atividades de montagem de HTML/CSS normalmente são realizadas por equipes distintas da equipe de desenvolvimento back-end, o desafio era mostrar as vantagens do uso do SVN para todos os envolvidos. Nesse modelo de segmentação de tarefa, normalmente os membros de equipes de front-end e back-end preferem não trabalhar concorrentemente no mesmo código e nem mesmo expor seu código antes que o mesmo esteja pronto para outra etapa. Como neste projeto estava sendo desenvolvido um CMS que suportaria vários sites, a estratégia adotada foi acordar que a equipe de back-end só passaria a dinamizar o conteúdo HTML depois do aval da equipe de front-end, mas que mesmo assim os envolvidos na etapa de front-end usariam o versionamento para manter o código fonte sincronizado entre eles.

Os desenvolvedores, que não tinham tido contato anterior com um sistema de versionamento ou tinha poucos conhecimentos a respeito, foram instruídos a realizar o procedimento de update (recuperação de atualizações do código fonte do servidor de versionamento) no início de cada jornada de trabalho e de commit (envio de atualizações do código fonte que foram realizadas localmente) a cada encerramento de jornada de trabalho.

Por falta de conhecimento, os desenvolvedores que não tinham tido experiência anterior com o SVN demonstraram desconfiança na capacidade da ferramenta de manter a integridade do código fonte e nas primeiras semanas ainda mantiveram o hábito de fazer backups manuais dos arquivos que faziam parte da solução. Havia o receio por parte deles de que em algum momento o sistema de controle de versão falhasse e houvesse uma perda de trabalho.

Enquanto a equipe de back-end prosseguia com o desenvolvimento do núcleo da aplicação, a equipe de front-end seguia montando, em HTML/CSS, as telas da área pública do CMS. Durante essa etapa não houve muita comunicação entre essas duas equipes, já que cada uma estava trabalhando em áreas distintas do software. Apesar da clara separação durante esta fase, o controle de versão entre os desenvolvedores da mesma equipe (tanto front-end quanto back-end) era realizado utilizando o SVN como ferramenta de controle e integração.

Durante o processo de desenvolvimento um novo membro, com experiência no uso de SVN, entrou na equipe de back-end e começou a executar atividades de forma remota. Foram fornecidos os dados de acesso para que esse novo desenvolvedor pudesse ter acesso, baixar a última versão disponível no servidor e iniciar sua participação. Essa flexibilidade evidenciou uma das vantagens do uso de um sistema de controle de versão, que é o acesso remoto ao repositório através da internet. Este desenvolvedor adicional tinha rotina de trabalho em horários diferenciados (executando suas atividades durante a noite), e através do SVN era possível para o líder de equipe verificar, no dia seguinte, o que foi feito e acompanhar a periodicidade e o volume das atividades desse desenvolvedor.

Um dos recursos importantes no SVN é a possibilidade de um desenvolvedor bloquear um arquivo (chamado de lock em inglês) de forma que outros não possam enviar alterações no mesmo até que haja o desbloqueio. Esse recurso visa evitar que dois desenvolvedores trabalhem de forma concorrente no mesmo arquivo e possam perder trabalho quando realizarem o commit ou update. Apesar desse recurso ser útil em casos críticos, foi verificado que seu uso cotidiano traz mais dificuldades do que benefícios.

É comum que diferentes desenvolvedores precisem fazer alterações no mesmo arquivo para atender diferentes demandas, mas verificamos que na maioria dos casos essas diferentes alterações eram em partes diferentes do mesmo arquivo, sendo possível utilizar o recurso de integração de versões (merge em inglês), que realiza a integração automática das modificações de diferentes desenvolvedores. Como as equipes estavam trabalhando em um processo muito dinâmico, o uso de locks, especialmente pelo desenvolvedor que trabalhava durante a noite, trouxe limitações, já que era necessário esperar que o bloqueio fosse liberado (o que só aconteceria, no mínimo, na noite seguinte), perdendo assim a equipe muito tempo para resolver algumas demandas de modificações necessárias de forma imediata.

O uso de locks deixou então de ser uma rotina e a equipe passou a utilizar o merge. Quando havia conflito era necessária uma verificação manual, e em algumas situações, uma conversa direta entre os envolvidos no conflito.

Com a adoção da estratégia de merges, parte da equipe começou a levantar desconfianças em relação à confiabilidade do processo automatizado de integração de alterações. Foram registrados alguns casos de erro da ferramenta e estes erros não eram relativos à sintaxe do código após a integração das versões, mas sim devido à inserção de caracteres estranhos no código, como “<<<<.”, em arquivos que sofreram o processo de merge. Em um período de dois meses de desenvolvimento tivemos cinco ocorrências desse tipo de erro, em um cenário de várias dezenas de merges realizados. Através de uma inspeção foi verificado que esses erros sempre ocorriam quando, por algum motivo não identificado, ocorria uma falha na transação de commit, que deveria ser atômica. A interrupção da transação por alguma falha, nesses casos, não estava sendo seguida de uma reversão automática e sim do aparecimento desses caracteres estranhos que são utilizados internamente pelo SVN para demarcar as regiões alteradas em uma determinada versão.

Além dos problemas relatados em relação ao merge, foram identificados no decorrer do desenvolvimento outros erros relativos ao plug-in VisualSVN. Em duas ocasiões, após a realização de um update, o projeto simplesmente deixou de estar vinculado a um repositório. Os arquivos fontes permaneciam intactos, mas o plug-in se comportava como se o desenvolvedor estivesse trabalhando em um projeto não controlado por um sistema de versionamento e sim de forma isolada. Os botões de ações do SVN, que se integram à IDE, assumiam o estado de desabilitados e deixava de ser possível realizar novos commits e updates. Como entre as opções disponibilizadas pelo plug-in não há a opção de reintegrar um projeto a um repositório existente (só é possível fazer um commit inicial ou um update inicial), foram necessárias intervenções manuais nesses casos. Foi feito o back-up de todo o projeto local e depois realizado o procedimento de recuperar todo o projeto do servidor (chamado de get solution from subversion) e as alterações recentes realizadas por aquele desenvolvedor foram copiadas manualmente para o código fonte que foi baixado novamente.

Conforme o andamento do desenvolvimento do projeto, toda a equipe foi se familiarizando com o sistema de versionamento e foi compreendendo melhor os recursos e limitações e isso permitiu que o número de ocorrência de falhas da ferramenta fosse diminuindo ao longo do tempo. Isso se deu por dois fatores: os desenvolvedores passaram a ter ciência das falhas da ferramenta e assim evitavam que os cenários que desencadeariam tais falhas acontecessem e, por outro lado, aprenderam a melhor forma de utilizar os recursos disponibilizados pela mesma. Os que não tinham tido nenhuma experiência com o sistema de versionamento passaram a fazer questionamentos com o intuito de sanar dúvidas quanto a questões conceituais de versionamento e também quanto aos recursos da ferramenta, e aos poucos começaram a identificar os benefícios do uso da mesma em contraponto ao processo manual.

Na etapa final do projeto, tanto a equipe de front-end quanto a de back-end começaram a trabalhar no mesmo conjunto de código fonte e muitas vezes nos mesmos arquivos, a fim de realizar integrações entre a interface da aplicação e os conteúdos dinâmicos que eram carregados pelos módulos desenvolvidos. Além de haver um ponto central onde todo o código estava disponível, o sistema de versionamento, nesta fase especificamente, permitiu que todos tivessem acesso a todo o código dos outros desenvolvedores, permitindo que os diferentes envolvidos (incluindo back-end e front-end) pudessem consultar o código de outros de forma a compreender melhor o que estava sendo feito e as necessidades que deveriam ser atendidas para que a integração entre a interface e os módulos da aplicação funcionasse corretamente.

Resultados

Após três meses de uso da ferramenta foi possível identificar os seguintes benefícios do uso do controle de versão com o Sistema de controle de versão em projetos web:

1. Permite que os desenvolvedores façam, regularmente, um back-up do seu trabalho em um servidor central;

2. Permite que múltiplos desenvolvedores trabalhem simultaneamente em um mesmo projeto e até mesmo em um mesmo arquivo de código fonte;

3. Minimiza substancialmente os problemas de integração que ocorrem quando os desenvolvedores trabalham separadamente;

4. Mantem o histórico das versões do software e permite saber o que mudou de uma versão para outra, assim como quem realizou a mudança e quando;

5. Permite a reversão de alterações;

6. Traz flexibilidade no acesso permitindo que desenvolvedores acessem o repositório via internet, caso essa opção esteja habilitada;

7. Possui recursos que permitem aos desenvolvedores compreenderem melhor a evolução do software, possibilitando recursos como “congelar uma versão”, “comparar os fontes de diferentes versões”, “juntar versões diferentes”;

8. Permite que o líder de equipe acompanhe a produtividade e regularidade das atividades dos desenvolvedores;

9. Permite ao desenvolvedor visualizar, na árvore de pastas e arquivos do projeto da IDE, o estado de cada arquivo em relação ao versionamento, mostrando através de ícones específicos se um arquivo foi alterado ou adicionado.

Por outro lado, foram identificados os seguintes pontos negativos no uso da ferramenta:

1. Instabilidade do plug-in em determinadas circunstâncias;

2. A necessidade de convencer desenvolvedores dos benefícios já que alguns tendem a desconfiar da ferramenta devido à ocorrência de falhas;

3. A incapacidade da ferramenta de integrar alterações concorrentes em arquivos binários;

4. A incapacidade de incluir na lista de versionados aqueles arquivos ou pastas que são adicionados diretamente na pasta do projeto, fora da IDE;

5. O custo de licenciamento quando o computador cliente está integrado a um diretório ativo (AD).

O uso de um sistema de controle de versão traz muitos benefícios para o efetivo controle do código fonte de um software desenvolvido em equipe e também pode ser aplicado em projetos web, inclusive na fase de montagem de HTML/CSS, integrando as etapas através do controle de versão, aumentando a produtividade e evitando falhas que ocorrem em processos de controle versões manuais. O uso de uma ferramenta que se integre à IDE traz facilidades e agilidade no controle e, principalmente, na visualização rápida em relação ao estado do versionamento.

A experiência do estudo de caso evidenciou que a ferramenta possui deficiências e limitações, mas que um treinamento adequado pode minimizar a ocorrência de erros e que os inúmeros benefícios suplantam suas limitações.

Melhorias no plug-in VisualSVN para Visual Studio são necessárias para que o nível de confiança no processo de sincronização aumente e seja evitada a perda de trabalho e a necessidade de correções manuais, que atrasam o desenvolvimento e levam aos que estão iniciando o uso da ferramenta à visão de que ela não é confiável.

Referências

Yuill, Simon. "Concurrent Versions System." Software Studies: A Lexicon (2008): 64.

Nagel, William A. "Subversion version control." (2005).

Boehm, Barry. "A view of 20th and 21st Century Software Engineering". Proceedings of the 28th international conference on Software engineering. ACM, 2006.

Apache Subversion
http://subversion.apache.org

VisualSVN
http://www.visualsvn.com