Quando um projeto multimódulo deve ser dividido em árvores de repositório separadas?

Question

Atualmente temos um projeto com um layout de repositório padrão do Subversion de:

./porta-malas
./galhos
./Tag

No entanto, à medida que avançamos no caminho do OSGi e de um projeto modular, acabamos com:

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0.0
./tags/bundle/main-1.0.1
./tags/bundle/modulea-1.0.0

A 'construção' ainda é bastante monolítica, pois constrói todos os módulos em sequência, embora eu esteja começando a me perguntar se deveríamos refatorar a compilação/repositório para algo mais parecido com:

./bundle/main/trunk
./bundle/main/tags/main-1.0.0
./bundle/main/tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea-1.0.0

Nesse padrão eu imaginaria cada módulo construindo a si mesmo e armazenando seu binário em um repositório (maven, ivy ou outro caminho do próprio repositório do Subversion).

Existem diretrizes ou 'melhores práticas' sobre layouts de projetos, uma vez que se torna modular?

Answer 1

O livro Subversion contém duas seções sobre isso:

• Layout do repositório
• Planejando sua organização de repositório

Uma entrada de blog sobre o assunto: "Layout do Repositório Subversion"

A resposta curta, porém:embora sua milhagem varie (cada situação é individual), sua /bundle/<project>/(trunk|tags|branches) esquema é bastante comum e provavelmente funcionará bem para você.

Answer 2

Isso depende muito da preferência pessoal, mas considero a seguinte estrutura adequada para grandes projetos que consistem em muitos módulos:

branches
  project-name
    module1
      branch-name
    module2   
      possibly-another-branch-name
    branch-name-on-a-higher-level-including-both-modules
      module1
      module2
tags
  ... (same as branches)
trunk
  project-name
    module1
    module2

Também tenho usado frequentemente a estrutura em grandes repositórios contendo muitos projetos, porque manter todos os projetos no mesmo repositório facilita a referência cruzada de projetos e o compartilhamento de código entre eles - com histórico.

Eu gosto de usar a estrutura com root trunk, tags e pastas de ramificações desde o início porque na minha experiência (com repositórios grandes contendo muitos projetos), muitos subprojetos e módulos nunca terão tags ou ramificações separadas, então não há necessidade de crie a estrutura de pastas para eles.Também torna mais fácil para os desenvolvedores verificarem todo o tronco do repositório e não obterem todas as tags e ramificações (das quais eles não precisam na maioria das vezes).

Acho que isso é uma questão de projeto ou política da empresa.Se você tiver um repositório para cada projeto ou se um determinado desenvolvedor provavelmente trabalhar apenas em um único projeto no repositório por vez, o tronco enraizado pode não fazer tanto sentido.

Answer 3

Apenas meus dois centavos...

Só quero enfatizar o comentário na documentação do SVN (já citado em outra resposta, mesmo tópico) http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

O trecho faz referência à seguinte estrutura:/ Trunk/ calc/ calendário/ planilha/… tags/ calc/ calendário/ planilha/… ramificações/ calc/ calendário/ planilha/

"Não há nada particularmente incorreto nesse layout, mas pode ou não parecer tão intuitivo para seus usuários.Especialmente em situações grandes, de vários projetos e com muitos usuários, esses usuários tendem a estar familiarizados com apenas um ou dois projetos no repositório.Mas os projetos como irmãos de ramo tendem a não enfatizar a individualidade do projeto e a focar no conjunto inteiro de projetos como uma entidade única.Essa é uma questão social.Gostamos do nosso arranjo sugerido originalmente por razões puramente práticas - é mais fácil perguntar sobre (ou modificar, ou migrar para outro lugar) todo o histórico de um único projeto quando há um único caminho de repositório que contém todo o histórico - passado, presente, marcado e ramificado - para esse projeto e somente para esse projeto."

Pessoalmente, tendo a concordar fortemente com isso e prefiro o seguinte layout:/ utils/ calc/ tronck/ tags/ ramificações/ calendário/ tronck/ tags/ ramiles/… Office/ Spreadsheet/ Trunk/ Tags/ Branches/

A razão é simplesmente que é impraticável marcar um conjunto completo de projetos quando se deseja marcar apenas um subconjunto específico.

Vamos usar um exemplo:Se o projeto-1 depender do móduloA v1.1 e do móduloB v2.3, não quero que o móduloA v2.x mais recente apareça nas tags.Na verdade, ao voltar alguns dias/semanas/meses depois para esta versão marcada, eu seria forçado a abrir o descritor de pacote na versão marcada do projeto-1 para ler a versão do móduloA realmente necessária.

Além disso, se eu tiver que fazer um backup específico dos fontes desta versão em um CD, eu só quero exportar essa tag sem baixar centenas de megabytes de material não relacionado.

Foram apenas meus dois centavos.

Answer 4

Eu respondi uma pergunta semelhante em um StackOverflow Pergunta sobre estrutura de controle de versão.Na verdade, ele se encaixa ainda melhor aqui, já que fazemos desenvolvimento pesado de OSGi e temos muitos pacotes.Devo repetir os comentários de Anders Sandvig:mantenha trunk/tags/branches no nível raiz, pois você ramificará apenas um conjunto limitado de módulos.Também não interfere na construção de módulos individualmente.

Não copiarei a resposta que dei antes, mas é totalmente relevante para esta questão.