Usando o Subversion para implantar aplicativos

3

Nós testamos o Subversion em vários projetos com clientes. Funcionou melhor do que eu esperava, mas existem algumas arestas.

Histórico:

  • O aplicativo registra automaticamente tudo o que é necessário, portanto, é seguro copiar apenas de um computador para outro.
  • Inclui muitos arquivos de configuração, tanto em texto quanto em binário (imagens vetoriais).
  • O aplicativo é instalado localmente em todos os computadores (para que possa ser usado sem acesso à rede).
  • O cliente atualiza arquivos e atualizamos arquivos para eles.

A solução atual é que trabalhe com um repositório Subversion em um de nossos servidores web. Eles instalam o TortoiseSVN se precisarem atualizar arquivos, caso contrário eles usam um arquivo bat com uma chamada para o cliente de linha de comando.

Desde que introduzimos o Subversion, tivemos zero problemas com uma instalação fora de sincronia. Nós também pudemos rastrear quando alguns bagunçaram as configurações (e descobrir por que isso aconteceu).

O problema:

Ocasionalmente você tem um conflito. Principalmente porque um usuário iniciante alterou uma das configurações por engano. Existe um svn-client que facilita a resolução de conflitos para usuários iniciantes?

(A solução atual em uma das empresas é excluir toda a instalação e executar uma nova verificação)

Editar: O projeto é normalmente uma versão personalizada do nosso aplicativo padrão. O número de usuários no local do cliente é de 2 a 10.

    
por Peter Olsson 11.05.2009 / 10:04

3 respostas

3

Nestes casos, o svn export é seu amigo, pois fornece um instantâneo 'limpo' do código. Minha sugestão é preparar suas implantações para testes e produção. Isso ajudará você a encontrar problemas de confirmação, como check-ins ou conflitos perdidos, pois você só recebe arquivos em uma revisão específica.

Para evitar alguns desses problemas, especialmente se você estiver preso ao svn, tente usar uma ramificação de produção. A ramificação de produção é mantida por um desenvolvedor experiente, que pode usar uma ferramenta de comparação multidirecional para extrair alterações das ramificações dos desenvolvedores. Como apontado por outros, o svn merge (ou mesmo update) pode ser propenso a erros, então este fluxo de trabalho permite que as mudanças sejam seletivamente mescladas, que é como o trabalho de dscm (como descrito por Richard).

    
por 11.05.2009 / 17:30
3

Uma das minhas preocupações com o Subversion é que ele vê tudo como uma série de versões, outros sistemas de controle de versão, como o Mercurial olhe para changesets (como mencionado no último Podcast de estouro de pilha). Essa faceta do Subversion torna a fusão inerentemente difícil, pois não sabe realmente o que mudou.

Como uma solução, que não é muito melhor que a sua solução atual, sugiro executar svn revert para redefinir a instalação antes de atualizar.

    
por 11.05.2009 / 10:28
1

O bom de um check-out em relação à exportação é que você pode ver quais alterações foram feitas pelos usuários que trabalham na cópia com check-out.

Se você quiser uma solução automatizada, você pode ter seu script de implantação salvando uma cópia das alterações em algum local (ou enviá-las para você) usando svn diff e, em seguida, fazer uma reversão antes da atualização.

    
por 12.05.2009 / 02:27

Tags