Estrutura de repositório SVN-por que isso é melhor?
- Repositório Principal
- pastas de projecto por baixo de
- cada pasta do projecto tem uma pasta principal, ramificações e marcas
então:
ReponsitoryMain
Project1
branches
trunk
tags
Project2
...
10 answers
Desta forma de organizar o repositório:
ReponsitoryMain
Project1
branches
trunk
tags
Project2
...
É melhor quando os teus projectos não estão assim tão ligados/dependentes um do outro. Ao contrário, torna mais fácil a versão de sua suíte de projeto inteira. Então, se você frequentemente liberar / empacotar o Project1 e o Project2 juntos, é melhor que eles compartilhem o mesmo ramo.
Se, por outro lado, o seu projecto estiver muito dissociado e tiver equipas totalmente diferentes a trabalhar nele, não precisaria de Os verificar todos juntos. a maior parte do tempo, e assim você poderia usar o método acima.A maioria das pessoas Faz isto porque é recomendado pelo livro Subversion .
Aqui está uma boa explicação do director do projecto CollabNet Subversion:
A estrutura do repositório depende de as suas necessidades. Se seus projetos estão totalmente separados (sem dependências entre eles), então esta estrutura de repositório "simples" é boa. Se tiver dependências no seu projecto (por exemplo, algumas "bibliotecas-ferramentas" globais, código partilhado) deverá usar uma estrutura diferente como:
trunk
prj_a
prj_b
tags
<YOUR_TAGNAME>
prj_a
prj_b
branches
<YOUR_BRANCHNAME>
prj_a
prj_b
Na estrutura simples com tronco/marcas/ramos locais não é possível (pelo menos numa limpar caminho) para marcar vários projetos, se você tiver dependências entre eles.
Também a abordagem "multi-repositório" muitas vezes proposta não irá preencher esta lacuna, uma vez que então você está condenado com várias revisões ou tags em múltiplos repositórios.
O principal problema é que o SVN não tem Suporte para recursos partilhados e marcá-los/ramificar.
Se pensar na sua estrutura do repositório, deve perguntar - se em que processo deseja partilhar o seu código biblioteca.
Ok, eu vou ser um pouco mais preachy e vir para baixo firmemente no lado de ter um tronco,tags & branches para cada projeto.
A principal alternativa é ter um único tronco,marcas e ramificações com todos os projectos por baixo. No entanto, isso leva a uma série de problemas, um dos quais é significativo e eu vou detalhar aqui:
Em primeiro lugar, abre o caminho para a biblioteca intocável, onde todos têm medo de tocar numa biblioteca em particular, porque qualquer mudança pode quebrar alguma coisa. subtil num projecto qualquer. A causa disso é que, como não há separação entre projetos, qualquer um pode efetivamente mudar o código em seu projeto sem que você seja capaz de detectá-lo ou controlá-lo.O que acontece é que um dia você verifica o seu projeto e ele se constrói, no dia seguinte você verifica e ele falha, mas você não fez nenhuma alteração {[[9]} para o seu projeto. O que aconteceu é que alguém mudou uma biblioteca da qual dependia. Numa grande estrutura com muitas dependências, é irrealista para um desenvolvedor para testar suas mudanças de biblioteca contra cada projeto, especialmente se eles têm que fazer mudanças quebrando. O que você precisa em seu projeto é uma referência a uma versão específica da biblioteca. Dessa forma, a biblioteca só é atualizada quando você muda a referência para a versão mais recente.
Este tipo de referência tem 3 Efeitos: 1 o seu projecto está isolado de alterações aleatórias de desenvolvimento intermédio na biblioteca. 2 você tem uma revisão em o seu projecto diz-lhe que "estou agora a usar esta versão da biblioteca". 3. Você começa a controlar quando você faz as mudanças em seu projeto para explicar quaisquer mudanças quebradas na biblioteca.
Há outras questões que posso resolver se isto não for suficiente.Mantemos um repositório separado para cada projecto.
Embora isto não lhe permita copiar e manter os ficheiros de histórico de versões de um projecto para outro, permite-lhe arquivar um repositório inteiro quando um projecto terminar.
M.
RepositoryMain
Trunk
proj 1
proj 2
..
Dev
Team1
proj 1
proj 2
Team2
proj 1
proj 2
...
Os ramos do tronco e as etiquetas agem todos da mesma maneira. A forma como os usas depende de ti.
Há anos que uso Esta estrutura e ainda não encontrei um tempo que a estrutura não se adaptasse ao que eu precisava de fazer.Em sistemas como o CVS, não mantiveste "directórios"separados. Só marcaste e ramificaste.
No entanto, SVN é modelado mais sobre a idéia de instantâneos, e, portanto, "cópias" de coisas são feitas de forma muito eficiente. Ao invés de marcar ou marcar versões especiais (ou alternativas) de um projeto, é mais fácil (e mais eficiente) fazer uma cópia com nome dele.
Gostaria de repetir as coisas acima com um pouco claro exp Digamos que fazemos a solução para um cliente ABC A solução é a aplicação TIcket/HelpDesk para os clientes da ABC Consultas
Digamos que o nome do aplicador é OneDeskApplication. Esta aplicação consiste de WebUI, Bibliotecas Partilhadas, Ferramentas De Compilação
Podemos desenhar a SVN assim?XSoftware.com/ABC -Repositório / tronco/ OneDeskWebUI Serviço OneDeskService OneDeskDBScript OneDeskBatchApp ramo/ Branch_Product_Support_1_0_0_0/ OneDeskWebUI Serviço OneDeskService OneDeskDBScript OneDeskBatchApp etiqueta/ OneDeskDocs OneDeskMasterBuild