Como Granular são seus “projetos” SVN: um grande projeto que contém vários aplicativos relacionados ou um projeto"' por aplicativo

Question

I definir um projeto como um diretório SVN contendo tronco, galhos, tags sub diretórios.

Que critérios você usa para determinar quando para dividir um projeto em dois ou consolidar vários projetos em um? - Uma App por "Projecto" com projetos compartilhados para fonte e recursos comum? -? Um "projeto" grande contendo todas as fontes e recursos para o aplicativo

projeto único ou múltiplo projeto ambos têm suas vantagens e menos. Estamos caminhando mais para um único projeto e eu estou tentando descobrir se esta é a abordagem correta.

projetos

Dividir permitir uma maior capacidade de controlar a forma como as diferentes partes do conjunto de incorporar uma mudança. A biblioteca comum pode ser a versão e diferentes aplicações podem optar por usar uma versão específica (maven dep abordagem de gestão).

projeto

Split também criar várias hierarquias de classe, tornando o código mais difícil de entender como um todo e, potencialmente levando à duplicação de código. Eu diria que o projeto apropriado da estrutura global e as relações entre os componentes seria a chave para gerir este custo.

A abordagem do projeto unificado vai tornar mais fácil para o desenvolvedor em termos de criação de um espaço de trabalho e fornecer uma única hierarquia de classes. Esta é uma faca de dois gumes, como também vai jogar muito mais informação ao desenvolvedor (muitas classes de compreender).

Assim, quando você está tentando decidir onde se combinam e onde para dividir, que regras de ouro que você usa?

Answer 1

Obrigado pela contribuição. Não vou "escolher" uma resposta porque acho que todos têm pontos valiosos em si. Evitando otimização prematura não parece chave como o faz manter o layout mais simples possível para o momento. Estamos caminhando para um único projeto contendo os aplicativos porque 90% do tempo nós liberamos todos juntos. Portanto, a questões complicar com um projeto de um aplicativos per-não parece fazer sentido. Mesmo quando vamos para maven é provável que todos os artefatos Maven para uma determinada versão será feita a partir do mesmo ramo. Nós sempre pode mudá-lo mais tarde, se for necessário usar a história SVN e olho de peixe para nos manter sã.

Vamos refazer o layout fonte apenas como nós refatorar a fonte. Quando um projeto começa a "mau cheiro" de uma situação cintura e dependência vamos dividi-lo, mas não antes disso. Eu provavelmente vou usar perímetros em tempo não girth no espaço: tempo para construir e teste, é hora de checkout. Se eu tiver uma árvore de 1GB que pode fazer o checkout em <10 minutos e build / teste em <30 minutos eu realmente não precisa quebrá-lo, a menos que eu sou obrigado a liberar partes dele com freqüência.

Assim, graças para a entrada. Foi muito útil no meu enquadramento da questão para mim equipe e avaliar as opções.

Answer 2

Nós colocar todos os projetos relacionados a um único aplicativo dentro de um SVN Rep simplesmente por uma questão de facilidade de manutenção, centralizando base de código do aplicativo em um repositório apenas e também capacidade de gerir as interdependências entre os diferentes recursos do aplicativo.

nós geralmente categorizar os nossos recursos em diferentes pastas dentro do tronco. essa classificação baseia-se principalmente no agrupamento funcional / modular ou em camadas agrupamento [DAL, BLL, GUI, etc.]. que é completamente até como você estruturou o código. Espero que isso ajude.

Answer 3

O SVN Livro tem uma boa discussão sobre ambas as abordagens.

No final, eu iria escolher o que se sente mais natural para os usuários do repositório.

Pessoalmente, eu favorecido um único SVN trunk / tags / ramos aproximar com todos os meus projetos de código reais em suas próprias pastas dentro delas.

No entanto, para um código-base maior (eu consegui apenas 3-4 pequenos projetos que faziam parte de uma única solução), eu altamente considerar a mudança para uma abordagem de divisão.

Answer 4

Eu uso os dois projetos separados e projectos combinados, dependendo do tamanho do projeto. Para os nossos grandes projectos, cada um é um repositório em separado, e tem de construção independente e os procedimentos de implantação. Para os nossos projectos mais pequenos, temos um "ferramentas" repositório para contê-los, com cada sub-projeto como um subdiretório da raiz.

Eu também manter um repositório "pessoal", onde as pessoas podem armazenar seus programas de teste utilitários, ou outras coisas que poderiam beneficiar de controle de origem e backups centralizados pontuais, mas não pertence como um projeto independente.

Answer 5

Eu uso projetos separados e combiná-las para formar uma solução através svn:. Externals

Answer 6

Um app / módulo que é implantado de forma independente por projeto. Usando um único projeto torna difícil introduzir os ciclos de lançamento, se você nunca descobrir o que você precisa Maven gerenciamento de dependência -ish com um módulo dependendo implementações estáveis ??de outros módulos. Ele também pode levar as pessoas apenas usando código útil de aparência aleatória de outros aplicativos diretamente em vez de factoring-lo para manter o gráfico de dependência Sane (tm).

Você deve fazer integração teste usando conjuntos de teste adequadas e práticas de IC no claramente definidos, não confiando em metade do seu código de falha, de repente, se uma parte breaks.

Outro problema com ter um único super-projeto é que ele é bastante oneroso para os usuários git-svn que só funcionam em um único módulo.

Answer 7

crescer organicamente. otimização pré é a raiz de todo o mal, Dijkstra disse uma vez. Também tenha Yangi (yagni) em mente.

Cada aplicativo tem sua própria pasta com trunk / tag / filiais. Se a um projeto dentro de uma aplicação fica muito grande, então ele é empurrado para a sua própria pasta separada e pode ser ligada à aplicação em tempo de compilação (ou mesmo svn: externos).

Dito isto, se seus requisitos de projeto são desenvolver uma aplicação complexa escrito por 10 desenvolvedores e você é o gatekeeper ou construção mestre, então você pode considerar alternativas mais complexas.

Answer 8

Mantenha repositórios SVN separados para projetos separados. A última coisa que queremos é ter um Mesclar Dia

Answer 9

Você pode querer verificar para fora Subversion número de revisão em vários projetos .

Answer 10

não há nenhuma resposta 'bom' aqui, mas eu acho que deveria haver uma distinção entre repos SVN que contêm 1 ou 2 projetos, e outros que contêm 100.

I manter um repositório SVN que foi migrado de VSS, ele tem várias centenas de "projetos" nele, nenhum deles foram organizados ao longo do ramo estrutura tag trunk / / (na verdade eu acho que a estrutura é realmente desnecessário e inútil depois que eu usei SVN por um tempo, ele certamente não ajuda quando você tem que tag 2 ou 3 projectos como uma única alteração).

Nós manter um diretório de projeto para todo o nosso software mantidos, sob que temos subdirs para configuração e outro para a fonte. Sob aqueles que têm números de versão do produto - de forma tão eficaz que estamos jogando fora o conceito de tronco, só temos diretórios tag - o maior número sendo o tronco (que temos que fazer isso como nós temos que apoiar várias versões dos projetos simultaneamente). A integração ocorre conforme necessário, então se eu atualizar um erro no projeto A, versão 3.0; Eu vou mesclar essas alterações para a versão 4.0 e v5.0.

Se eu fosse fazer um repo com apenas 1 ou 2 projectos, I pode ser tentado a manter a estrutura ramo / tag, mas por outro lado - eu provavelmente manter os diretórios explícita na árvore principal (supondo que eu não divulgou muitas vezes suficiente para tag regularmente) (eu uso o número de revisão como um 'tag' BTW, e eu armazenar binários lá. Então, se eu preciso para obter uma revisão de idade particular, eu posso pegar o binário direito de olhar para o log)

Sua surpreendentemente fácil de gerenciar considerando que eu tenho um repo 10Gb com um revnum atualmente até passado 300.000 com lotes de código antigo lá, bem como mais recente. Eu recomendaria a estrutura para os outros e vai usá-lo novamente.

A propósito, um outras tags razão dir não funcionaria para nós é porque nós liberamos cada vez que há um bug ou solicitação de alteração, não importa quão pequena. Nosso diretório tags seria incontrolável depois de um tempo, é por isso que usamos o revnum como uma tag -. Podemos associá-lo com o bug tracker para mantê-lo mais legível demasiado

Assim, para resumir em bruto, temos uma estrutura de diretório como este onde v1 e v2 são versões de produtos:

maint/source/v1.0/projectA
maint/source/v1.0/projectB
maint/source/v2.0/projectA
maint/source/v2.0/projectB
etc

Obviamente, poderíamos colocar um dir ramo sob 'fonte', e um ramo / tag em cada subprojeto também, mas que se tornaria complicado se que precisávamos para liberar 2 subprojetos como um único pedido de mudança (como fazemos com bastante frequência). Colocar um subdir tag sob a dir fonte significaria que tag tudo, quando apenas um único subprojeto tem mudado (não se encaixa com a nossa exigência de rastrear cada subprojeto individualmente)