Um repositório SVN ou muitos?

Se você tiver vários projetos não relacionados, é uma boa ideia colocá-los no mesmo repositório?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

ou você criaria novos repositórios para cada um?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

Quais são os prós e os contras de cada um? Tudo o que posso pensar atualmente é que você obtém números de revisão mistos (e daí?), E que você não pode usar a svn:externalsmenos que o repositório seja realmente externo. (eu acho que?)

A razão de eu perguntar é porque estou considerando consolidar meus vários repositórios em um, já que meu host SVN começou a cobrar por repositório.

A questão única versus múltipla se resume à preferência pessoal ou organizacional.

O gerenciamento de múltiplo versus único se resume principalmente ao controle de acesso e manutenção.

O controle de acesso para um único repositório pode estar contido em um único arquivo; Vários repositórios podem exigir vários arquivos. A manutenção tem problemas semelhantes - um grande backup ou muitos pequenos backups.

Eu gerencio meu próprio. Há um repositório, vários projetos, cada um com suas próprias tags, tronco e ramos. Se um ficar muito grande ou eu precisar isolar fisicamente o código de um cliente para seu conforto, posso criar um novo repositório de maneira rápida e fácil.

Recentemente, consultei uma empresa relativamente grande sobre a migração de vários sistemas de controle de código-fonte para o Subversion. Eles têm cerca de 50 projetos, desde aplicativos muito pequenos até aplicativos empresariais e seu site corporativo. Seu plano? Comece com um único repositório e migre para vários, se necessário. A migração está quase completa e eles ainda estão em um único repositório, sem reclamações ou problemas relatados por ser um único repositório.

Este não é um problema binário, preto e branco.

Faça o que funciona para você - se eu estivesse em sua posição, combinaria projetos em um único repositório tão rápido quanto pudesse digitar os comandos, porque o custo seria uma consideração importante em minha (muito, muito pequena) empresa.

JFTR:

números de revisão no Subversion realmente não têm significado fora do repositório. Se você precisa de nomes significativos para uma revisão, crie um TAG

As mensagens de confirmação são facilmente filtradas por caminho no repositório, portanto, ler apenas aquelas relacionadas a um projeto específico é um exercício trivial.

Edit: Consulte a resposta do Blade para obter detalhes sobre o uso de uma única configuração de autorização / autenticação para SVN.

Para o seu caso específico, um (1) repositório é perfeito. Você economizará muito dinheiro. Sempre incentivo as pessoas a usarem um único repositório. Porque é semelhante a um único sistema de arquivos: É mais fácil

• Você terá um único lugar onde procura o código
• Você terá uma única autorização
• Você terá um único número de commit (já tentou construir um projeto distribuído por 3 repositórios?)
• Você pode reutilizar bibliotecas comuns e monitorar seu progresso nessas bibliotecas (svn: externals são PITA e não resolverão todos os problemas)
• Projetos planejados como itens totalmente diferentes podem crescer juntos e compartilhar funções e interfaces. Isso será muito difícil de conseguir em vários repositórios.

Há um único ponto para vários repositórios: a administração de repositórios enormes é desconfortável. Despejar / carregar repositórios enormes leva muito tempo. Mas como você não faz nenhuma administração, acho que não será da sua conta;)

O SVN escala muito bem com repositórios maiores, não há lentidão mesmo em repositórios enormes (> 100 GB).

Portanto, você terá menos problemas com um único repositório. Mas você realmente deve pensar sobre o layout do repo!

Eu usaria vários repositórios. Além do problema de acesso do usuário, também facilita o backup e a restauração. E se você se encontrar em uma posição em que alguém quer pagar por seu código (e seu histórico), é mais fácil dar a eles apenas um despejo de repositório.

Eu sugeriria que consolidar repositórios apenas por causa das políticas de cobrança de seu provedor de hospedagem não é um motivo muito bom.

Usamos um único repositório. Minha única preocupação era a escala, mas depois de ver o repositório do ASF (700 mil revisões e contando), fiquei bastante convencido de que o desempenho não seria um problema.

Nossos projetos são todos relacionados, diferentes módulos interligados que formam um conjunto de dependências para qualquer aplicativo. Por esse motivo, um único repositório é o ideal. Você pode querer trunk / branches / tags separados para cada projeto, mas ainda é capaz de comprometer atomicamente uma alteração em toda a sua base de código em uma única revisão. Isso é ótimo para refatorar.

Esteja ciente de que, ao tomar sua decisão, muitos repositórios SVN podem compartilhar o mesmo arquivo de configuração.

Exemplo (retirado do link acima):

Em casca:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

Arquivo: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

Arquivo: / var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

Eu criaria repositórios separados ... Por quê? Os números de revisão e mensagens de confirmação simplesmente não farão nenhum sentido se você tiver muitos projetos não relacionados em apenas um repositório, será com certeza uma grande confusão em curto prazo ....

Somos uma pequena empresa de software e usamos um único repo para todo o nosso desenvolvimento. A árvore tem esta aparência:

/client/<clientname>/<project>/<trunk, branches, tags>

A ideia era que tivéssemos cliente e trabalho interno no mesmo repo, mas acabamos tendo a nossa empresa como “cliente” dela mesma.

Isso funcionou muito bem para nós, e usamos o Trac para fazer a interface com ele. Os números de revisão abrangem todo o repositório e não são específicos de um projeto, mas isso não nos deixa em fases.

Pessoalmente, eu criaria novos repositórios para cada um. Ele mantém o processo de check-out muito mais simples e facilita a administração em geral, pelo menos no que diz respeito ao acesso do usuário e backups. Além disso, evita o problema do número de versão global, portanto, o número da versão é significativo em todos os projetos.

Na verdade, você deve apenas usar git;)

uma coisa adicional a se considerar é o fato de que usar vários repositórios faz com que você perca a capacidade de ter um registro unificado (comando svn log), isso por si só será uma boa razão para escolher um único repositório.

Eu uso o TortuiseSvn e descobri que a opção "Mostrar Log" é uma ferramenta obrigatória. embora seus projetos não estejam relacionados, tenho certeza de que você descobrirá que ter informações centralizadas de projetos cruzados globais (caminhos, ids de bugs, mensagens e assim por diante ...) é sempre útil.

Se você planeja ou usa uma ferramenta como o trac que se integra com o SVN, faz mais sentido usar um repo por projeto.

Semelhante à sugestão de Blade sobre o compartilhamento de arquivos, aqui está uma solução um pouco mais fácil, mas menos flexível. Eu configurei o nosso assim:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

Em "bin", mantenho um script chamado svn-create.sh que fará todo o trabalho de configuração de criação de um repositório vazio. Eu também mantenho o script de backup lá.

Em "repository_files", mantenho os diretórios "conf" e "hooks" comuns para os quais todos os repositórios têm links simbólicos. Então, há apenas um conjunto de arquivos. Isso elimina a capacidade de ter acesso granular por projeto sem quebrar os links. Essa não foi uma preocupação onde eu configurei isso.

Por último, mantenho o diretório principal / var / svn sob controle de origem, ignorando tudo em svnroot. Dessa forma, os arquivos e scripts do repositório também estão sob controle de origem.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Semelhante ao mlambie de usar um único repo, mas foi um pouco mais longe com a estrutura de pastas para facilmente ampliar para tipos específicos de projetos - projetos baseados em html da web vs. cs (C #) vs. sql (criar / executar scripts SQL) vs. xyz ( Idiomas específicos de domínio, como afl (AmiBroker Formula Language) ou ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Observe, eu tenho o tronco ativo dentro dos ramos, pois o trato como o ramo padrão. A única dor às vezes é quando você deseja criar rapidamente outro projeto, você precisa construir a estrutura ProjectName / branches | tags. Eu uso app-settings simplesmente como um lugar para manter arquivos de configurações de Apps específicos no repo tão facilmente compartilháveis ​​com outros (e substituo ClientName por VendorName e ProjectName por AppName nesta estrutura de pasta; e as tags branches podem ser úteis para marcar configurações em diferentes principais versões de produtos de fornecedores também).

Bem-vindo a quaisquer comentários sobre minha estrutura - recentemente mudei para isso e até agora estou muito feliz, mas às vezes acho difícil manter estruturas branches | tags por projeto - particularmente se o projeto for simplesmente uma configuração de projeto simplesmente para Teste de Unidade de outro projeto.

Minha sugestão é uma. A menos que você tenha usuários diferentes acessando cada um, eu diria que use vários.

Mas, novamente, mesmo isso não é um bom motivo para usar vários.