Número de revisão do Subversion em vários projetos

StackOverflow https://stackoverflow.com/questions/15674

  •  08-06-2019
  •  | 
  •  

Pergunta

Ao usar o Subversion (svn) para controle de origem com vários projetos, notei que o número de revisão aumenta em todos os diretórios dos meus projetos.Para ilustrar meu layout svn (usando nomes de projetos fictícios): 

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

Quando realizo um commit no trunk do Programa Ninja, digamos que ele foi atualizado para a revisão 7.No dia seguinte, digamos que eu faça uma pequena alteração no aplicativo Stealth e ele volte como revisão 8.

A questão é esta: É uma prática comum aceita, ao manter vários projetos com um servidor Subversion, aumentar o número de revisões de projetos não relacionados em todos os projetos? Ou estou fazendo errado e deveria criar repositórios individuais para cada projeto?Ou é algo totalmente diferente?

EDITAR: Demorei em sinalizar uma resposta porque ficou claro que há razões para ambas as abordagens e, embora essa pergunta tenha surgido primeiro, gostaria de apontar algumas outras perguntas que, em última análise, fazem a mesma pergunta:

Devo armazenar todos os projetos em um repositório ou em vários?

Um repositório SVN ou muitos?

Foi útil?

Solução

Estou surpreso que ninguém tenha mencionado que isso é discutido em Version Control with Subversion, que está disponível gratuitamente online, aqui.

Eu li sobre o assunto há algum tempo e realmente parece uma questão de escolha pessoal. Há uma boa postagem no blog sobre o assunto aqui.EDITAR: Como o blog parece estar fora do ar, (versão arquivada aqui), aqui está um pouco do que Mark Phippard tinha a dizer sobre o assunto.

Estas são algumas das vantagens da abordagem de repositório único.

  1. Administração simplificada.Um conjunto de ganchos para implantar.Um repositório para backup.etc.
  2. Flexibilidade de ramificação/etiqueta.Com o código todo em um repositório fica mais fácil criar um branch ou tag envolvendo vários projetos.
  3. Mova o código facilmente.Talvez você queira pegar uma seção de código de um projeto e usá-la em outro, ou transformá-la em uma biblioteca para vários projetos.É fácil mover o código dentro do mesmo repositório e reter o histórico do código no processo.

Aqui estão algumas das desvantagens da abordagem de repositório único e vantagens da abordagem de repositório múltiplo.

  1. Tamanho.Pode ser mais fácil lidar com muitos repositórios menores do que com um grande.Por exemplo, se você retirar um projeto, você pode simplesmente arquivar o repositório em mídia e removê-lo do disco e liberar armazenamento.Talvez você precise descarregar/carregar um repositório por algum motivo, como para aproveitar um novo recurso do Subversion.Isto é mais fácil de fazer e com menos impacto se for um repositório menor.Mesmo que você eventualmente queira fazer isso em todos os seus repositórios, terá menos impacto fazê-los um de cada vez, supondo que não haja uma necessidade urgente de fazê-los todos de uma vez.
  2. Número de revisão global.Mesmo que isso não deva ser um problema, algumas pessoas percebem que é um problema e não gostam de ver o número de revisão avançar no repositório e que projetos inativos tenham grandes lacunas em seu histórico de revisões.
  3. Controle de acesso.Embora o mecanismo authz do Subversion permita restringir o acesso conforme necessário a partes do repositório, ainda é mais fácil fazer isso no nível do repositório.Se você tiver um projeto que apenas algumas pessoas selecionadas devem acessar, isso será mais fácil de fazer com um único repositório para esse projeto.
  4. Flexibilidade administrativa.Se você tiver vários repositórios, será mais fácil implementar diferentes scripts de gancho com base nas necessidades do repositório/projetos.Se você quiser scripts de gancho uniformes, então um único repositório pode ser melhor, mas se cada projeto quiser seu próprio estilo de email de commit, será mais fácil ter esses projetos em repositórios separados

Quando você realmente pensa, os números de revisão em um repositório de vários projetos vão aumentar, mas você não vai acabar.Lembre-se de que você pode visualizar um histórico em um subdiretório e ver rapidamente todos os números de revisão pertencentes a um projeto.

Outras dicas

Acho que é altamente recomendável que você crie repositórios separados para cada projeto.Pelo menos para evitar o cenário de que você está falando.

Com o controle de versão, especialmente o Subversion, você pode facilmente transferir partes de um repositório para outra cópia de trabalho e então enviá-las de volta para seus respectivos repositórios.Isso permite mantê-los claramente separados e distintos, ao mesmo tempo que oferece muita flexibilidade.Depois de entrar um pouco mais no SVN (presumo que você seja novo), você pode começar a usar ganchos e posso ver onde isso pode ficar difícil com sua configuração.Se a permissão for importante para você, um único repositório pode ser mais difícil do que o necessário.

Além disso, se você estiver preocupado com o fato de que levará muito tempo para configurar cada repositório, procure na variável SVNParentPath o arquivo de configuração do Apache.(Novamente, presumo que você esteja usando o Apache.)

Isto se deve ao modo como a subversão funciona.Cada revisão é na verdade um instantâneo do repositório identificado por aquele número de revisão.Se todos os seus projetos compartilham um repositório, isso é inevitável.Normalmente, na minha experiência, você configuraria repositórios separados para projetos completamente não relacionados.A resposta curta é não, você não está fazendo nada de errado, é uma pergunta comum em torno do subversão, mas faz sentido quando você pensa em como ele armazena informações do repositório.

O número de revisão deve ser apenas um identificador para uma versão específica.Se é sequencial para um projeto ou não, não importa.Dito isto, posso entender que não é o ideal.

A maioria dos projetos que encontrei foram configurados em um único repositório e os IDs de revisão se comportam dessa maneira.Não conheço nenhuma opção de configuração SVN para alterar esse comportamento e, IMHO, manter vários repositórios parece uma sobrecarga desnecessária.

Temos apenas um repositório com tudo, exatamente como no seu exemplo.

Não vejo nada de errado nisso - o único requisito para o número de revisão é que seja

  • Exclusivo
  • Atômico
  • Maior do que era no último check-in

Não importa se aumenta em 1 ou 50 a cada commit, no que me diz respeito.

@grom:

Então, sempre que inicio um novo projeto, apenas executo:

svnadmin create /var/www/svn/myproject

Posso ver que isso funciona bem se você tiver apenas 1 ou 2 desenvolvedores, mas o que acontece se as pessoas que estão criando novos projetos não tiverem acesso shell no servidor SVN para poder criar diretórios em /var/www ?

Recomendado usar repositório separado por projeto.No meu diretório Apache conf.d eu tenho subversion.conf que contém:

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

Então, sempre que inicio um novo projeto, apenas executo:

svnadmin create /var/www/svn/myproject

Hm, onde trabalho temos todos os nossos projetos no mesmo repositório.Eu realmente não vejo vantagem em separá-los, isso não cria apenas muito trabalho extra - criação de novos repositórios, concessão de acesso a pessoas, etc.?Acho que repositórios separados fazem sentido se os projetos não estiverem relacionados e você tiver, digamos, clientes externos que precisam ter acesso ao repositório.

No meu local de trabalho, temos dois repositórios.Um com acesso público de leitura e outro para todo o resto.Eu usaria apenas um para tudo, mas precisamos de direitos de acesso diferentes para projetos públicos/privados.

Dito isto, pessoalmente não vejo problema com o aumento dos números de revisão a cada atualização.Os números de revisão podem pular números primos e pares e ainda fazer o que deveriam fazer.Facilite o acesso a uma revisão específica.

Se a alteração dos números de revisão com base em outros projetos incomoda você, coloque os projetos em repositórios separados.Essa é a única maneira de tornar os números de revisão independentes.

Para mim, o grande motivo para usar repositórios diferentes é fornecer controle de acesso separado para usuários e/ou usar diferentes scripts de gancho.

Talvez seja melhor não criar necessariamente um repositório por "projeto", mas sim um repositório por "solução" (para usar os termos do Visual Studio).Se você tiver vários "projetos" em pastas diferentes, mas eles estiverem relacionados entre si, coloque-os no mesmo repositório.

Eu armazeno um projeto por repositório e, como no anterior Comentarista nisto questão de subversão, marco os projetos compartilhados como externos, para que eles estejam no controle de origem apenas uma vez.

Estou apenas começando a adicionar um servidor de construção de CI (CruiseControl.NET), então terei que ver como tudo funciona, mas se meus scripts de construção estiverem corretos, não deverá ser um problema.

Além da aparência, é realmente uma questão de preferência (na minha opinião).

Quando você realmente pensa, os números de revisão em um repositório de vários projetos ficarão altos, mas você não vai acabar.Lembre -se de que você pode visualizar um histórico em um sub -diretório e ver rapidamente todos os números de revisão que pertencem a um projeto.

Na verdade, se você estiver construindo o código da Microsoft e usar os números de revisão do svn como parte da string de sua versão, poderá acabar.O compilador da Microsoft gerará um erro se qualquer parte da string da versão for maior que 65535....No nosso caso, temos um repositório enorme na revisão 68876 e acabamos de bater nessa parede.

Um repositório por projeto.

O comentário de Steven Murawski sobre CC.NET é interessante.Eu estaria interessado em saber como funciona se você precisar especificar vários repositórios de controle de origem.

@Daniel Fone:Os documentos do SVN recomendam um projeto por repositório, então esse é definitivamente o caminho que os criadores pretendiam que fosse.Como você pode ter um servidor (apache ou svnserve) mantendo vários repositórios, nunca tive problemas de sobrecarga excessiva.Com Servidor VisualSVN, instalar um servidor Apache e configurar vários repositórios é muito fácil.

Não tenho certeza se os documentos do SVN realmente recomendam um projeto por repositório.Principalmente eles falam sobre as vantagens e desvantagens de cada caminho.Acontece que eu uso três repositórios diferentes, um para 7 ou 8 projetos que estão todos relacionados, tornando muito bom poder enviar cópias compatíveis de todos os projetos apenas construindo a partir de uma revisão (ou verificando se eles são compatíveis olhando nos números de revisão de cada um).O segundo repositório possui outro grupo de projetos e documentos relacionados, enquanto o terceiro é muito menor.Isso nos permite aproveitar o fato de que os projetos relacionados podem ser gerenciados por um único número de revisão, mas os projetos não relacionados não afetam seu repositório.

Os números de revisão não têm uso semântico.A única coisa é que eles estão em ordem sequencial.Se você despejar seu projeto e importá-lo em outro repositório, suas versões poderão obter novos números de revisão.Então NUNCA use os números de revisão para marcar seus lançamentos ou coisas semelhantes.Faça tags para lançamentos (cópias da revisão relevante).

Tive o mesmo problema na minha empresa anterior, eles costumavam ter cerca de 50 projetos rodando em um repositório e era um pesadelo trabalhar nos mesmos projetos porque ao fazer atualizações de svn outros amaldiçoariam... haha...

Uma coisa que aprendi que sempre funciona melhor: Um projeto, Um Repo... você nunca se arrependerá.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top