Neste momento, minha empresa está usando um compartilhamento de rede para se comunicar com o repositório SVN. É muito lento, então eu gostaria de mudar para o SVNSERVE.
A razão principal pela qual minha empresa escolheu a rota do sistema de arquivos foi porque facilitou a segurança usando nosso sistema de autenticação de diretório ativo existente.
Pelo que eu li, é possível usar SvnServe com o diretório ativo, contanto que você use a biblioteca Sasl . Eu estava apenas imaginando se alguém mais está fazendo isso e poderia dar algumas dicas sobre a configuração, já que ela não parece estar documentada em lugar nenhum.
Obrigado
Edições
Temos o svn em um servidor rápido, mas infelizmente ele é usado para outros compartilhamentos e serviços de arquivos corporativos.
Estou me dizendo que o protocolo HTTP não será mais rápido do que file: // com o SMB. Alguém tem alguma documentação disso. Eu imaginei que um modelo de servidor cliente verdadeiro teria um desempenho melhor. Temos cerca de 13 desenvolvedores e um servidor de compilação confirmando e atualizando a partir dele o dia todo.
Vá a rota simples morta e instale o servidor Visual SVN.
Instale-o em um servidor associado ao seu Active Directory. Agora você tem SVN em http (s) com autenticação AD. Gerencie as permissões usando a útil ferramenta MMC dandy que acompanha. De 0 a implantado em cerca de 15 minutos.
Lembre-se de que file: // access não é recomendado para repositórios SVN, é mais para ferramentas de administração. O problema com o acesso a arquivos é que você não tem nenhum servidor no meio para garantir que todas as gravações sejam escritas corretamente. Então pare de usá-lo o mais rápido possível.
O Svnserve (ou Apache) é muito melhor, mas você terá os mesmos problemas de desempenho - ele não vai melhorar, porque sua rede usa protocolos http ou svn em vez de smb. Se o seu acesso está lento hoje, ele ainda será lento, a menos que você faça alguma coisa sobre sua rede ou sistema de arquivos (ou qualquer outra coisa que esteja tornando isso lento).
No entanto, a migração para o Apache ou o Svnserve vale a pena ser feita por si só.
Existe um problema com o svnserve e as bibliotecas sasl, como mencionado recentemente na lista de discussão do svn. O problema é que o protocolo svn não permite texto simples, mas somente o auth de texto simples é permitido pelo saslauthd. Resultado final - ele simplesmente não funciona e é um problema conhecido .
Não é de todo ruim, se você estiver rodando no Windows, basta instalar o VisualSVN Server. É a parte superior do pacote e fornece uma instalação do Apache, sendo executada como um serviço do Windows completo com gerenciamento de snap-in e autenticação de diretório ativo com apenas um clique de um botão de opção durante a instalação. Você pode até mesmo colocar acls em diretórios ou arquivos no repositório.
Se não, eu ainda recomendaria o Apache, pois a configuração é melhor documentada e suporta a autenticação LDAP (que funciona com o AD). Há muitas postagens no blog descrevendo como fazer isso.
O desempenho do http em vez do svn será mais lento, mas duvido que você o perceba, a menos que você instale lado a lado e faça o checkout / commit de um diretório grande. Experimente - você pode servir um repositório Apache-servido com o Svnserve ao mesmo tempo. (embora eu verifiquei essa afirmação antes de colocá-la em prática).
Desculpe, não há Svnserve com as autorizações do Windows. Ainda assim, eu uso o Svnserve com o SASL e gerencio manualmente as contas, porque o número de programadores reais usando o SVN aqui é muito baixo.
O fato de você estar disposto a arriscar o compartilhamento de arquivos do Windows para fazer SVN mostra que você deve estar em uma situação desesperada, então eu recomendo o SSL através do Apache, onde você pode obter a autenticação do Windows. Está usando SSL em vez de SVN, mas está perto o suficiente. Aqui vai você:
mod_auth_sspi no Apache e configure-o
no httpd.conf que vem com
Servidor Subversion da CollabNet. Eu executo HTTPS e SVN, mas pessoalmente prefiro gerenciar manualmente as contas SASL para obter o bit extra de velocidade do protocolo SVN, que é um pouco mais rápido que o HTTPS.
Em suma, trocar seu repositório SVN de um compartilhamento de rede para SVNServe ou Apache / WebDAV não melhorará o desempenho de seus clientes. No máximo, os clientes verão um desempenho pior.
Claro, o acima assume que você está planejando continuar executando o repositório no mesmo servidor que atualmente o hospeda. Se você mover seus repositórios SVN para um servidor mais poderoso, poderá ver uma melhoria no desempenho.
Você verificou se o servidor atual está sobrecarregado? Ele está servindo muitos clientes / arquivos não-SVN também? Nesse caso, você provavelmente verá uma melhoria no desempenho movendo seus repositórios SVN para um servidor dedicado. Se você tiver vários repositórios em um servidor, considere dividi-los em mais de um servidor. (Você pode dividir repositórios únicos existentes em vários repositórios, se necessário, para ajudar com isso.)
Realmente, porém, você precisa descobrir por que o desempenho existente é ruim. Analise a carga no servidor atual, primeiro. O desempenho é geralmente limitado pela capacidade de algum recurso do sistema, principalmente sua RAM, CPU, taxa de E / S de disco, capacidades de E / S de rede. Tente responder a estas perguntas:
Sua CPU está vinculada a 100% ou você tem muitos ciclos livres? O uso da CPU pode variar, mas se a média for igual ou próxima a 100%, talvez você precise de CPUs maiores / mais rápidas.
Quanta RAM livre você tem (em% do total)? Quanto espaço de troca você está usando (novamente, em% do total)? Se a sua RAM livre for inferior a 10%, você pode estar ficando sem RAM, o que força o sistema a usar a troca de disco. Isso diminui tudo, mas é pior para você porque a troca compete com a atividade do SVN por E / S de disco limitado.
Quantos dados (transferência em massa) você está movendo para / do disco, por segundo? Quantas buscas por segundo o seu disco está executando? Quanto tempo são suas filas de disco? Os discos do seu servidor devem ser classificados para transferência de dados em massa e taxas de busca. (Se não, você pode compará-los por conta própria.) Se as taxas médias de transferência e de busca estiverem próximas ou no máximo, você precisará usar discos mais rápidos. Se você estiver usando o RAID, adicione mais discos de uma maneira que aumente o desempenho. Se você não estiver usando o RAID, comece a usá-lo.
Quantos dados de rede você está transferindo para / do servidor, por segundo? Se essa taxa se aproxima de 80-90% do máximo nominal (por exemplo, 10Mbit / s, 100Mbit / s, 1Gbit / s), você provavelmente está atingindo os limites do seu link de rede. (Observe que NICs mais baratas ou drivers ruins podem ter limites máximos substancialmente mais baixos - teste seu link para ter certeza.) Tente atualizar para um link mais rápido ou veja se os drivers da NIC suportam ligação (também chamada de "agregação de link" ou "ligação de canal"). ) para aumentar o desempenho.
Dadas as respostas a estas perguntas para o seu ambiente, tente aumentar a capacidade de quaisquer recursos que sejam limitados. Isso pode significar uma atualização ou substituição do servidor ou possivelmente uma atualização da rede.
Não é exatamente o mesmo, mas eu tenho um repositório svn em um servidor Linux. O servidor não está executando o svnserve, mas permite que os usuários usem o svn sobre o ssh. Como o servidor Linux é um servidor membro do AD e os usuários também são do AD, essa é uma solução bastante fácil e segura.