Gerenciamento de versões no SVN

Question

Quando eu olho no SVN log Eu realmente gostaria de poder ver marcadores que me dizer quando lançamentos foram feitos. Eu já vi isso em outros sistemas de controle de versão, como PVCS e Perforce .

Isso pode ser feito no SVN? Eu fiz um pouco de pesquisa e até agora parece que esse tipo de coisa não é suportado.

Editar

Não quero ter que copiar a nossa fonte para uma pasta diferente para cada versão. Isso resulta em uma enorme quantidade de duplicação desnecessária de arquivos na máquina desenvolvedores e só nos dá um registro do número de revisão de cada lançamento. Eu posso fazer isso usando um documento de texto!

Edit2

Meu objetivo é ter uma visão única que me mostra uma cronologia dos meus lançamentos, entre os quais eu posso ver todas as alterações de código que ocorreram entre cada lançamento. Isso, então, faz com que seja mais fácil para compilar notas de lançamento.

Answer 1

Richard, tags são muito perto, mas me pergunto se o que você precisa pode não ser um ramo release dedicado.

Por isso, fazer um ramo de tronco cedo chamado algo como 'Release'. Em seguida, trabalhar no tronco como normal, quando você estiver pronto para um lançamento, mesclar as alterações do tronco para 'Release'. Esta é a única maneira que você deve modificar lançamento.

Você pode então tag de liberação, se quiser, não é 100% necessário.

Mas o que isso vai lhe dar é um ramo que tem um subconjunto das revisões do tronco na mesma. Descubra as datas de lançamento com:

svn log --stop-on-copy svn://server/project/branches/release

Isto lhe dará uma lista de datas de lançamento (com as revisões). Para ver o que há em cada liberação fazer:

svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>

Além disso, observe que, trabalhando desta forma, você não está limitado a uma liberação estritamente seqüencial de tudo no porta-malas - você pode cereja escolher revisões, excluindo revisões se você não quer liberá-los ainda, mas ainda incluindo posterior revisões.

Answer 2

Não como tal. A forma aceita para fazer lançamentos no SVN é ter um diretório "tags", onde sua fonte de liberação é copiado para cada versão particular. Por exemplo /tags/release-0.11 ... Não há nada impedindo-o de mexer com o diretório tags por acidente, fora da caixa, mas algumas pessoas gostam de configurar pré-commit ganchos para prevenir commits acidentais para liberar tags.

Aqui está um artigo decente descrevendo um processo de liberação no SVN.

Answer 3

Meu objetivo é ter uma visão única que me mostra uma cronologia dos meus lançamentos, entre os quais eu posso ver toda a alterações de código que ocorreram entre cada versão.

Você já investigou o gráfico de revisões Tortoise SVN? Se você marcar cada versão (que, como outros apontaram não envolve a cópia de arquivos, seja no servidor ou estação de trabalho), então você pode ver todas as revisões em ordem cronológica, com as tags que indicam lançamentos reais. Você pode diff entre os lançamentos e / ou tronco por hilighting as duas revisões você está interessado em e selecionando diff no menu de contexto.

Answer 4

Copiar o tronco para um caminho de marcas no repositório SVN é a maneira de conseguir isso. É uma cópia svn, então não acabar com duplicatas de arquivos no servidor repositório SVN. Você só tem arquivos duplicados localmente se você escolheu para finalizar compra um que não seja o tronco caminho SVN. Compromete sobre essas cópias de trabalho, em seguida, voltar para o caminho svn eles estavam check-out do.

Esta é essencialmente uma aplicação convencional específica de ramificação no svn. Dê uma olhada no livro SVN on-line para obter mais detalhes.

Answer 5

O marcador seria a mensagem escrita quando uma tag para o lançamento é feito (uma cópia svn aos / tags) cometer. Pelo menos esse é o método mais comum usado.

Answer 6

Ainda que o Subversion não fornece gerenciamento de liberação, por si só, ferramentas de controle de versão não são normalmente encarregado de esta atividade. O que você está procurando é uma questão ferramenta de atividade / / mudança de gestão que pode interagir com o Subversion.

Para o efeito usamos Jira no meu local de trabalho e que vinculá-lo com o Subversion. Jira fornece um histórico roteiro e mudança que inclui questões em cada lançamento. Cada um desses problemas possui links para as mudanças no controle de código fonte. Assim você pode ligar mudanças no código-fonte com versões lançadas.

Eu acho que é geralmente melhor para manter essas duas ferramentas separadas. Embora Perforce em tentativas particulares para amarrar os dois juntos, eles fazê-lo apenas simplesmente. Existem algumas coisas, como e-mail usuários de mudanças para as questões, acrescentando comentários a questões, adicionar anexos a questões que são muito melhor feito em um pedaço especializada de software como Jira. Por outro lado Jira não é muito bom em versionamento, fusão e ramificação fonte ... que é melhor tratado em um pedaço especializada de software como o Subversion.

Para a divulgação completa, existem outras ferramentas que Jira como Bugzilla, Trac, IBM Rational Jazz, etc. que podem fazer a mesma coisa com o Subversion que Jira faz embora com diferentes níveis de funcionalidade.

Answer 7

Dê uma olhada em tópicos do livro SVN:

Etiquetas e navegação do repositório

tags e Ramos são "cópia na escrita", o que significa que não há cópias extras no repositório. Geralmente um desenvolvedor individual não precisa ter uma cópia local, a menos que ele precisava para uma razão (ou seja, o desenvolvimento de um ramo).

Se você marcar cada versão, então você pode ver as marcas de navegação do repositório. Os links acima falar diretamente sobre as ferramentas de linha de comando, mas também existem ferramentas GUI como TortoiseSVN no Windows. Você pode obter história, fazer comparações, etc.

Para ver as alterações feitas em um comunicado, que seria apenas mostrar um log do tronco a partir da revisão da tag que você quer de volta para revisão do tag anterior +1. Parece que o trabalho extra, mas é bastante simples uma vez que você se acostumar com isso.

Com as nossas ferramentas de compilação, que também cometem volta um arquivo com algumas informações número da versão de volta para o tronco, eo comentário tem o número de versão da compilação. Se o código principal é no tronco, isso pode também trabalhar como um marcador para o que está em uma compilação (olhar entre os commits versão).

Answer 8

+1 para usar a mensagem de confirmação.

Para um projeto que eu criei um usuário SVN chamado de construção. A máquina de compilação utilizado este login para SVN. Sempre que a máquina / processo de construção fez uma compilação também atualizou um arquivo eo SVN cometer mensagem era a versão / outro identificador para a construção.

Então nós também criou uma tag para essa construção. Desta forma, no tronco pudemos ver as compilações quando / onde são intercaladas com outras mudanças.

Assim, a minha sugestão (maneira mais simples de fazê-lo) é criar mais arquivos chamados de construção (ou então você quer alguma coisa) e acrescentar a essa ou apenas modificá-lo no seu script de construção / processo e, em seguida, verificá-lo de volta em / cometê-lo com o nome da versão como a mensagem de confirmação. Simples. Ela irá então aparecer em suas consultas de história.

Answer 9

Além disso, se você sabe quais as revisões que você está comparando você pode fazer um diff SVN e você vai ver quais arquivos mudaram e como entre as duas revisões.

Não tenho certeza sobre a configuração total, mas alguém mencionada TortoiseSVN. Isso é definitivamente um bom começo. Eu pessoalmente uso o Eclipse com o plug-in subclipse e me permite realizar diffs em um ambiente gráfico entre revisões. Contanto que você tem seu projeto seu pode comparar qualquer revisão a qualquer outra revisão e, como tal, você não precisa ter todo o tipo de duplicação de arquivos.

Além disso, nós geralmente configurar três diretórios em cada repositório. Ramos, tronco e tags. Como alguém observou, tags são usadas especificamente para a identificação de autorização.

Answer 10

I encontrar o mesmo problema ea maneira Tentei corrigi-lo para a minha empresa é ter uma pasta 'libertação' no tronco, esta pasta contém apenas o executável real ou o que precisa fazer parte da implantação.

I criar uma nova pasta para cada liberação começando com pasta '1.0.0.0' em 'release' e também marcar o código com a mesma liberação nome da pasta ou seja 1.0.0.0 no caso.

Eu não tenho certeza se ele é o caminho certo para fazê-lo, mas ele resolve o meu problema para descobrir o executável que eu implantado.

Answer 11

Se você seguir a convenção svn normal de "tags / ramos / trunk" na raiz do seu repositório, os desenvolvedores normalmente não gostaria confira todo o repositório, somente a partir do baixo tronco.

Answer 12

Eu gostaria de oferecer uma abordagem diferente, que deve ajudar a resolver o seu problema declarou: criar notas de lançamento e ver as diferenças de código entre os lançamentos.

Nós usamos um utilitário chamado SubWCRev que vem com Tortoise SVN. Nós temos um evento pós-compilação que agarra o número de revisão do SVN e paus-lo em um arquivo - no caso de sites que colocar isso em um arquivo chamado version.html. Em seguida, em qualquer ponto do tempo, você pode amarrar o seu lançamento (se isso é o releas atualmente em QA, Prod, ou qualquer outro ambiente) para o número de revisão exata no SVN. Não há mais a marcação, não mais perguntando o que está incluído em um release, não mais incomodando desenvolvedores para atualizar um arquivo de versão.

A fim de determinar o que é foi incluído em um release, você pode em seguida, basta puxar para cima os logs SVN de revisão X para revisão Y e copiar os comentários em um documento e editar para fazer uma bonita notas de lançamento doc. O mesmo é verdadeiro para revisão de código ou diffing os lançamentos; basta usar os números de revisão amarrados ao seu version.html, properties.cs, readme.txt, etc.

Eu também sugerem ter algum tipo de repositório de artefatos para segurar sua cria. Se você passar a usar o número de revisão do SVN como o número da versão, pode sempre voltar a essa revisão exata no SVN que significa que você fazer etiquetas ou cópias de sua fonte para cada lançamento, que volta no SVN não precisa.

Answer 13

FYI,

copy

SVN não é hard-cópia, é só ligar, portanto, não terá qualquer espaço diferente de arquivos alterados. E essas versões terá espaço de qualquer maneira. Assim, a criação de uma cópia para cada lançamento não terá qualquer espaço.