Como você estrutura seu repositório SVN? [fechadas]

Question

O que é melhor?

A:

server:1080/repo/projectA/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...
server:1080/repo/projectB/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...

B:

server:1080/repo/trunk/projectA/...
                 branches/projectA/branch1
                 branches/projectA/branch2
                 branches/projectA/branch3
                 tags/projectA/tag1/...
                 tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
                 branches/projectB/branch1
                 branches/projectB/branch2
                 branches/projectB/branch3
                 tags/projectB/tag1/...
                 tags/projectB/tag2/...

O que estrutura do repositório que você usa e por quê?

Answer 1

capítulo do The Administração do Repositório SVN livro inclui uma seção sobre Planejando a Organização do Repositório delineando estratégias diferentes e suas implicações, particularmente as implicações do layout repositório de ramificação e mesclagem .

Answer 2

Nós usamos A, porque o outro não faz sentido para nós. Note-se que um "projeto" em relação ao SVN não é necessariamente um único projeto, mas pode ser de vários projectos que pertencem em conjunto (ou seja, o que você colocar em uma solução no Visual Studio). Desta forma, você tem alguma coisa relacionada agrupados. Todos os ramos, tags e tronco de um projeto específico. Faz todo o sentido para mim.

O agrupamento por ramo / etiqueta vez não faz sentido para mim, porque os ramos de diferentes projectos têm nada em comum, exceto que eles são todos os ramos.

Mas, no final, as pessoas usam os dois lados. Faça o que quiser, mas quando você decidiu, tente ficar com ele:)

Como uma adição: Temos repositórios separados por cliente, ou seja, todos os projetos para um cliente estão no mesmo repositório. Desta forma, você pode, por exemplo, fazer backups de um único cliente de uma só vez, ou dar o código fonte de qualquer coisa que o cliente possui a ele sem lutar com SVN.

Answer 3

Gostaria de sugerir uma opção C:

server:1080/projectA/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...
server:1080/projectB/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...

Eu prefiro manter projetos separados em repositórios separados. Usando svn: externals torna mais fácil para gerenciar projetos de biblioteca de código que são compartilhados entre dois ou mais projetos de aplicação.

Answer 4

Use a configuração B. Beause é mais fácil de verificar / Tag vários projetos ao mesmo tempo. Em svn 1.5 é possível através de check-out esparso, mas não é uma operação de um clique. Você quer usar configuração B, se alguns projetos têm escondido dependências inbeetween.

Answer 5

Nós usamos

/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags

O que eu estou começando a me arrepender. Ele deve ser mais plana. Isso seria melhor.

/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags

Por quê? Produtos (componentes, software acabado) durar para sempre. Projetos vêm e vão. No ano passado, há apenas uma equipe de projeto criando produtos quux. No próximo ano, que a equipa é dispersa e uma ou duas pessoas a manter quux. No próximo ano, haverá dois projetos de expansão quux grandes.

Dado que cronograma, deve quux aparecem em três repositórios do projeto? Não, quux é independente de qualquer projeto específico. É verdade que os projectos têm produtos de trabalho (documentos, cadernos, etc.) que fazem parte de começar o trabalho feito, mas não são o objetivo real do trabalho. Daí o "ProjectX" repositórios para que o material -. Coisas que ninguém vai se importar com depois que o projeto é feito

Eu trabalhei em um produto que tinha três equipes. Grande problema com a coordenação do trabalho, porque cada projeto gerenciado é repositório de forma independente. Havia lançamentos inter-equipe e coordenação inter-equipe. No final, em seguida, do dia, que era suposto um pedaço de software. No entanto, como você pode imaginar, foi três peças de software com sobreposições estranhos e redundância.

Answer 6

Pessoalmente eu uso seguinte estrutura repositório:

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

Há também um diagrama ilustrando como os diretórios são usados . Também há versão numeração uso específico abordagem que eu. Ela desempenha papel significativo na estruturação do repositório. Recentemente eu desenvolvi formação dedicado a Software de Gerenciamento de Configuração onde eu descrever a abordagem de numeração de versão e por que exatamente esta estrutura repositório é o melhor. Aqui estão slides da apresentação .

Há também o meu na href="https://stackoverflow.com/questions/1761513/multiple-svn-repositories-or-single-company-repository/"> sobre 'múltiplas SVN Repositories vs repositório única empresa'. Pode ser útil, desde que você abordar esse aspecto de estruturação repositório na sua pergunta.