Melhor maneira de estruturar um repositório em projetos do Subversion para Visual Studio?

Question

Eu tenho alguns C# .dll projetos que são comuns a muitas aplicações.Atualmente, tenho um grande repositório.Tenho cada DLL armazenada como um projeto separado no repositório e cada projeto de aplicativo armazenado como um projeto no mesmo repositório.

Recentemente mudei para o Subversion para controle de origem e temo não ter feito um bom trabalho na estruturação do repositório.Eu gostaria de ouvir o que os outros estão fazendo.

Answer 1

usar a estrutura de repositório branch/trunk/tag é bastante padrão, mas se estou entendendo bem, seu problema é que você tem um conjunto de projetos DLL comuns que são usados ​​em vários projetos.Definitivamente, isso pode se tornar difícil de gerenciar.

Portanto, o cenário típico aqui é que você tem alguma biblioteca de classes chamada Common.Helpers que possui código comum a todos os seus aplicativos.

Digamos que estou iniciando um novo aplicativo chamado StackOverflow.Web que precisa fazer referência a Common.Helpers.

Normalmente, o que você faria é criar um novo arquivo de solução e adicionar um novo projeto chamado Stackoverflow.Web e adicionar o projeto Common.Helpers existente e, em seguida, referenciá-lo no novo projeto Stackoverflow.Web.

O que eu normalmente tento fazer é criar um repositório para o projeto Common.Helpers e então no subversion referenciá-lo como um externo.Dessa forma, você pode manter o código sob controle de origem em um único local, mas ainda usá-lo separadamente em vários projetos.

Answer 2

Os repositórios do Subversion são normalmente subdivididos em:

branch/
tags/
trunk/

Você colocaria todos os seus projetos de DLL e aplicativos no porta-malas e então use filial e Tag para todos eles conforme necessário também:

branch/
tags/
trunk/
    project1/
    project2/

Alternativamente, você pode criar pastas para cada projeto na raiz e então colocar o branch comum, tags e pastas tronco dentro delas.

project1/
    branch/
    tags/
    trunk/

project2/
    branch/
    tags/
    trunk/

Observe que esta prática é simplesmente uma convenção e nada no SVN exige (ou realmente promove) fazer exatamente dessa maneira.Porém, todo mundo está acostumado.Então, você estaria fazendo um favor às pessoas se concordasse.

Para elaborar mais, o porta-malas é onde seu principal desenvolvimento ocorrerá.Quando você deseja marcar uma revisão específica (por exemplo,uma versão de lançamento), então simplesmente svn cópia de o projeto no diretório tags.Além disso, basta copiar o código no filial diretório quando você deseja fazer algo dramático ou prolongado e não quer impedir o progresso no porta-malas.Mais tarde você pode svn mesclar seu filial de volta para o porta-malas quando estiver pronto para a ação!

Se você deseja corrigir contratempos em seu repositório Subverion atual, basta usar svn mover para realocá-los.Ao contrário do processo de exclusão e adição de CVS, a movimentação manterá o histórico da versão do novo local.

Answer 3

se seus subprojetos puderem ser lançados em versões diferentes (como controles, web parts, etc...), então pode fazer sentido construir sua estrutura assim:

Solução
Projeto 1

• Filial
• Tag
• Porta-malas

Projeto 2

• Filial
• Tag
• Porta-malas

Dessa forma, você pode gerenciar cada versão do projeto de forma independente.

Caso contrário, a estrutura mais comum é:

• Filial
• Tag
• Porta-malas
• Documentos (opcional)

Answer 4

Eu armazeno tudo no repositório para facilitar aos desenvolvedores (ou devboxes reconstruídos) fazer check-out do SVN e, em seguida, executar uma compilação (com todos os assemblies necessários em caminhos relativos).Se você tiver vários projetos que deveriam ser separados, isso também incentivaria a equipe de seus componentes compartilhados a entregar montagens de alta qualidade.Isso poderia seguir uma mentalidade de lançamento normal para produção, onde a montagem compartilhada seria atualizada em seus projetos posteriores.Isto é muito natural Cadeia de Valor de Software, ao custo de um pouco de espaço em disco.

JP Boodhoo tem uma ótima série sobre o tópico de compilações automatizadas, estrutura de pastas VS e colocação dos desenvolvedores em funcionamento rapidamente.

Answer 5

Obrigado a todos que responderam.lomaxx, passei a manhã pensando em usar o recurso externo e parece que esse é o caminho a seguir.Eu não estava ciente disso, provavelmente porque não é exatamente proeminente no Tortoise.

Answer 6

Se você quiser usar o rastreamento de mesclagem do Subversion 1.5 em mais de um projeto ao mesmo tempo, você deve usar uma única árvore sem elementos externos.

Uma mesclagem rastreada ocorre (assim como um commit) sempre sobre um diretório e seus filhos.

A mesma regra se aplica a commits atômicos.(Funciona estável apenas em uma única cópia de trabalho.Pode funcionar em alguns outros casos específicos, mas esse comportamento não é garantido)