Manipulação de relações entre vários projetos de subversão

Question

Na minha empresa, estamos usando um repositório SVN para manter o nosso código C ++. A base de código é composto de uma parte comum (infra-estrutura e aplicações), e projetos de clientes (desenvolvido como plugins).

O layout aparência de repositório como este:

• Infra-estrutura
• App1
• App2
• App3
• projeto-para-cliente-1
  • App1-plugin
  • App2-plugin
  • Configuração
• projeto-para-cliente-2
  • App1-plugin
  • App2-plugin
  • Configuração

A libertação típico para um projecto de cliente inclui os dados do projecto e cada projecto, que é usada por ela (por exemplo, infra-estrutura).

O layout real de cada diretório é -

• Infra-estrutura
  • ramos
  Tags
  • tronco
• projeto-para-cliente-2
  • ramos
  Tags
  • tronco

E o mesmo vale para o resto dos projectos.

Temos vários problemas com o layout acima:

1. É difícil iniciar um ambiente de desenvolvimento fresco para um projeto do cliente, uma vez que se tem que fazer o checkout todos os projetos envolvidos (por exemplo: Infra-estrutura, App1, App2, o projeto-de-client-1).
2. É difícil marcar um lançamento em um projetos de clientes, pela mesma razão que acima.
3. No caso de um projeto cliente precisa alterar algum código comum (por exemplo, infra-estrutura), que, por vezes, usar um ramo. É difícil manter o controle que ramos são usados ??em projetos.

Existe alguma maneira no SVN para resolver qualquer um dos acima? Pensei em usar svn: externos nos projetos de clientes, mas depois de ler este post Eu entendo que pode não ser a escolha certa.

Answer 1

Você poderia lidar com isso com svn: externos. Esta é a URL para um local em um repo svn Isso permite que você puxar a partes de um repositório diferente (ou a mesma). Uma maneira de usar este é no âmbito do projecto-for-client2, você adicionar um svn: externos apontam para o ramo da infra-estrutura que você precisa, o ramo da app1 você precisa, etc. Então, quando você check-out do projeto-de-client2, você começa todas as peças corretas.

O svn:. Externals ligações são versionadas juntamente com tudo mais, então como projeto-de-client1 ficar marcado, ramificado, e atualizado os ramos externos corretos sempre terá puxado

Answer 2

A sugestão é a disposição dos diretórios mudança de

• Infra-estrutura
  • ramos
  Tags
  • tronco
• projeto-para-cliente-1
  • ramos
  Tags
  • tronco
• projeto-para-cliente-2
  • ramos
  Tags
  • tronco

para

• ramos
  • recurso-1
    • Infra-estrutura
    • projeto-de-client-1
    • projeto-de-client-2
Tags
• tronco
  • Infra-estrutura
  • projeto-de-client-1
  • projeto-de-client-2

Existem alguns problemas com este esquema também. Ramos tornou massiva, mas pelo menos é mais fácil para locais específicos tag no seu código.

Para trabalhar com o código, seria simplesmente o checkout do tronco e trabalhar com isso. Então você não precisa os scripts que verificar todos os projetos diferentes. Eles só se referem a Infra-estrutura com "../Infrastructure". Outro problema com este esquema é que você precisa fazer check-out várias cópias se você quiser trabalhar em projetos de forma totalmente independente. Caso contrário, uma mudança na infra-estrutura para um projeto pode causar um outro projeto não para compilar até que seja atualizado também.

Isso pode fazer lançamentos um pouco mais complicado também, e separando o código para diferentes projetos.

Answer 3

Sim, é uma porcaria. Nós fazemos a mesma coisa, mas eu realmente não posso pensar em um melhor layout.

Então, o que temos é um conjunto de scripts que podem automatizar tudo subversão relacionado. O projeto de cada cliente irá conter um arquivo chamado project.list, que contém todos os projetos de subversão / caminhos necessários para construir esse cliente. Por exemplo:

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

Cada script, em seguida, é algo como isto:

for PROJ in $(cat project.list); do
    # execute commands here
done

Onde os comandos pode ser uma saída, atualização ou tag. É um pouco mais complicado do que isso, mas isso não significa que tudo é consistente, check-out, atualização e marcação torna-se um único comando.

E, claro, nós tentamos ramo tão pouco quanto possível, que é a sugestão mais importante que eu posso possivelmente fazer. Se precisamos ramo alguma coisa, vamos tentar quer trabalhar fora do tronco ou a versão previamente marcado como muitas das dependências quanto possível.

Answer 4

Em primeiro lugar, eu não concordo que aparências são maus. Embora eles não são perfeitos.

No momento você está fazendo vários checkouts para construir uma cópia de trabalho. Se você usou externos que faria exatamente isso, mas automaticamente e de forma consistente a cada vez.

Se você apontar seus externos para tags (e ou revisões específicas) no âmbito dos projectos-alvo, você só precisa tag do projeto atual a cada lançamento (como a tag indicaria exatamente o externo que estavam apontando para). Você também teria um registro dentro do seu projeto de exatamente quando você mudou suas referências externals a usar uma nova versão de uma biblioteca particular.

Externals não são uma panacéia - e, como os shows pós pode haver problemas. Tenho certeza de que há algo melhor do que externos, mas eu não tê-lo encontrado ainda (mesmo conceitualmente). Certamente, a estrutura que você está usando pode produzir uma grande quantidade de informação e controle em seu processo de desenvolvimento, utilizando externos pode adicionar a isso. No entanto, os problemas que ele tinha não eram questões fundamentais de corrupção -. A ficar limpo iria resolver tudo, e são muito raros (? Você é realmente incapaz de criar um novo ramo de uma biblioteca em sua repo)

Pontos a considerar - usando externos recursiva. Eu não estou vendido tanto no sim ou não deste e tendem a ir com uma abordagem pragmática.

Considere o uso de pistão como o artigo sugere, eu não vi isso em ação assim não pode realmente comentário, ele pode fazer o mesmo trabalho como externos de uma maneira melhor.

Answer 5

Da minha experiência eu acho que é mais útil ter um repositório para cada projeto individual. Caso contrário, você tem os problemas que você diz e, além disso, números de revisão mudar se alterar outros projectos que pode ser confuso.

Apenas quando há uma relação entre projectos individuais, tais como software, esquemas de hardware, documentação, etc. Nós usamos um único repositório para o número de revisão serve para obter o pacote inteiro para um estado conhecido.