Como usar o Subversion para a linguagem não-compilado?

Question

Eu quero usar o Subversion com um sistema de desenvolvimento baseada em script, e queria saber o que fazer de forma diferente para a minha situação usual (C # /. NET).

A atualização normal do dia-a-dia / commit ciclo vai funcionar bem, como vai mudar rastreamento e comparação das revisões. Onde eu gostaria de alguns conselhos é em torno de manipulação de implantação.

Com este sistema de script, não há nenhuma etapa de compilação distinta envolvidos - em vez disso, a implantação envolve o upload de um script selecionado diretamente no aplicativo host.

Alterações a um script não são necessariamente incluído no próximo lançamento - que pode ser destinado para a liberação depois disso, ou a um depois disso.

Em um mundo ideal, eu gostaria de ser capaz de alocar um script em uma determinada versão, dizem que a liberação "September 2009", uma vez que foi testado, e depois retirar todos os scripts para que a liberação com uma única comando.

Atualizar

Tanto quanto eu posso dizer, nem Tag nem changelists vão ser a resposta.

changelists não são persistentes (não existem no repositório) e eu preciso de uma solução que irá permitir a revisão muito mais tarde.

Tags são efetivamente o mesmo que ramos - eles contêm todas arquivos por padrão, e você só pode escolher qual revisões.

Eu estou esperando por uma abordagem que iria começar com uma ramificação vazia na qual revisões de arquivos específicos poderia ser colocado como necessário.

Update 2

Dois exemplos, mostrando como eu posso atender a essa situação com featues em outras ferramentas. Note que eu não estou tentando promover essas ferramentas em tudo, como eu quero usar a subversão, eu só estou tentando descobrir como.

Com QVCS , eu posso alcançar o meu resultado desejado pela aplicação de um rótulo para uma revisão específica de um arquivo. Esse rótulo iria ficar no lugar, anexado a essa revisão do arquivo. A qualquer momento, eu poderia fazer um checkout limpo, em um diretório vazio, e especificar que apenas os arquivos com o rótulo especificado deve ser copiado para baixo.

Da mesma forma, com StarTeam , eu posso aplicar uma etiqueta a uma revisão do arquivo e verificar apenas os arquivos com esse rótulo.

Answer 1

"Em um mundo ideal, eu gostaria de ser capaz de alocar um script em uma determinada versão, dizem que o '' lançamento em setembro de 2009, uma vez que foi testado, e depois retirar todos os scripts para que liberar com um único comando ".

Este é exatamente o que etiquetas são projetados para.

Answer 2

Você pode gerenciar seus "futuros" lançamentos com ramos Subversion. Quando você faz uma alteração que é destinado para um futuro lançamento, cometê-lo para o ramo apropriado. Quando chega a hora de puxar todos aqueles futuro apresenta no tronco, mesclar o ramo.

Isto não é realmente tudo o que diferente do fluxo de trabalho para usar o Subversion com uma linguagem compilada, ou mesmo para qualquer outra finalidade.

Veja a seção do os padrões Comum ramificação livro do Subversion para mais informações. Em particular, os "ramos de funções" seção sons mais adequados à sua situação.

Answer 3

Uma solução seria começar de um novo ramo usando svn mkdir (em vez de svn copy), e depois copiar seletivamente os arquivos necessários do seu ramo principal por meio de svn copy

Answer 4

Eu vejo o problema - que não tem nada a ver com SVN. Você deseja armazenar alguns arquivos em um ramo de lançamento, mas não outros. Assim, ou ramificar em todo o diretório de liberação e, em seguida, apagar os arquivos que você não quer mostrar lá dentro; ou criar um novo diretório vazio e copiar apenas os arquivos que você deseja.

A sua é tão simples. Você não precisa changelists ou tags ou qualquer coisa complicado em tudo, e nenhum sistema subversão será capaz de adivinhar quais arquivos você quer. Pessoalmente, eu faria o ramo Option + Delete como então você pode desfazer a exclusão em uma data posterior, se você decidir que deseja que os arquivos de volta.

Answer 5

Acredito que com SVN 1,6 você pode ter externos que apontam para arquivos individuais. Então, se você quiser, você pode criar uma estrutura de árvore vazia e definir um conjunto de fatores externos sobre ele que trazem os arquivos que deseja na estrutura. Isto lhe daria uma espécie de 'visualização ao vivo' de um ramo.

Você poderia talvez referenciar as versões de arquivo diretamente do tronco - ou você pode camada seu abordagem e usar um ramo release fundindo nomeadamente revisões, e em seguida, referência que ramo release nos externos da sua 'visão ao vivo'. Dessa forma, você liberar recursos através da fusão revisões -. Manter o controle de revisão normal e história merge, e em seguida, um svn-update no servidor iria puxar esses arquivos na estrutura vivo

A desvantagem seria que seria difícil de mudar para um ramo diffrerent (dizem que uma tag de idade, devido a um problema na nova versão) - você teria que editar manualmente todas as suas definições externas. Isto pode não ser um problema se eles estão todos no mesmo diretório, mas poderia ser uma dor, se você tem que caçar ao redor para eles.

A pouca informação sobre externos de arquivo estão disponíveis no svn 1.6 notas de lançamento

Answer 6

Parece que você está procurando metadados sobre scripts específicos. Assim, uma opção é armazenar seus scripts como arquivos separados e use propriedades svn . propriedades svn permitem pares chave-valor de lojas associadas a um arquivo.

Por exemplo, para espelhar o seu exemplo "rótulo", você poderia criar uma propriedade para cada arquivo que você decidir incluir em uma versão particular. Neste caso, crie uma propriedade "September 2009" com o valor "verdadeiro".

Você pode então selecionar apenas os arquivos com a propriedade "September 2009" ao gerar o seu pacote de implementação.

Usando tags e ramos são úteis quando você deseja acompanhar as alterações em seu repositório ao longo do tempo, e gerar diffs para ver o que essas mudanças são - mas é um instantâneo de todo o repositório ...