Podemos configurar o servidor svn em um computador local sem acesso à rede?

Desejo configurar um repositório SVN no meu computador sem nenhum acesso à rede. Como estou trabalhando em um código sem nenhum colaborador, não quero que ele esteja disponível ao público.

Eu li este post , mas ele sugere o uso de serviços de repositório SVN online que oferecem repositórios gratuitos. Nesse caso, meu código estará disponível ao público (conforme incluído nos termos dos planos gratuitos).

Então, eu queria saber se posso configurar um servidor local na minha máquina Windows XP que somente eu acesso mesmo quando não tenho conexão com a Internet?

A maneira mais fácil de configurar um servidor local é usar svnserve :

O Subversion inclui o Svnserve - um servidor autônomo leve que usa um protocolo personalizado em uma conexão TCP / IP comum. É ideal para instalações menores ou onde um servidor Apache completo não pode ser usado.

Você realmente não precisa de um servidor subversion, se tudo o que você quer fazer é acessar o repositório localmente, pois você pode acessar um repositório subversion através de uma URL de arquivo, conforme descrito nesta resposta :

Você pode acessar o repositório usando o protocolo file: // para que você só precise do Tortoise SVN instalado e nada mais. Veja esta pergunta na FAQ: É possível usar o TortoiseSVN sem um servidor?

Você pode até ter o repositório no dispositivo USB para poder levar a fonte com você e trabalhar com outros computadores.

Se você estiver usando o TortoiseSVN , poderá encontrar instruções em Criando o repositório com o TortoiseSVN :

1. Abra o Windows Explorer

2. Crie uma nova pasta e nomeie-a, por exemplo, SVNRepository

3. Clique com o botão direito do mouse na pasta recém-criada e selecione TortoiseSVN → Criar Repositório aqui ....

Imediatamente acima nesta página também descreve como criar um repositório a partir da linha de comandos .

Dito isto, eu recomendaria que você desse uma olhada no Mercurial ou no Git como uma alternativa svn. Se você estiver familiarizado com o TortoiseSvn, encontrará o TortoiseHg e o TortoiseGit uma transição fácil, além de oferecer a flexibilidade de trabalhar de maneira distribuída mais tarde, se necessário. Por exemplo, no passado, usei cartões de memória para transferir hgrepositórios entre máquinas sem acesso à rede e, quando você trabalha dessa maneira, obtém um backup gratuito por uma pechincha.

Servidor mais simples (e mais rápido), que você pode usar para trabalhar com repositório local, incorporado em cada cliente svn . Este é um servidor para acessar qualquer repositório e qualquer quantidade de repositórios existentes no sistema de arquivos local, usando o arquivo de protocolo: ///. Ele não fornece nenhum método de autorização ou autenticação, concede apenas acesso ilimitado ao repositório sob controle, mas, por outro lado, permite o uso e fornece todos os recursos do sistema VCS por si só.

Para usar este servidor, você tem em qualquer diretório vazio, em qualquer local, chamada CLI-comando svnadmin com o subcomando e os parâmetros correspondentes (não me lembro, existem programas administrativos no pacote cliente-CLI ou não e não posso verifique - eu não instalei o CLI svn-client, apenas o TortoiseSVN, que possui esses programas no instalador na versão 1.7) - Espero que você possa encontrá-lo.

svnadmin helpnos mostrar todos os subcomandos disponíveis, agora estamos interessados ​​no subcomando create.

svnadmin help create fornecer todos os detalhes necessários para nós

create: usage: svnadmin create REPOS_PATH

Create a new, empty repository at REPOS_PATH.

Valid options:
...

No ponto de partida do primeiro repositório, podemos ignorar todas as opções de ajuste fino e lembrar apenas do formulário principal svnadmin create REPOS_PATH, pois REPOS_PATH é um caminho absoluto ou relativo para o diretório vazio, planejado para o repositório. Como na maioria das vezes as pessoas comuns do Windows para aplicativos de plataforma cruzada podem confundir as pessoas, qual notação (barras invertidas ou avançadas) usar no caminho (metoo), a maneira mais segura é o cdlocal, a partir do qual nosso diretório é visível sem o caminho longo - pai do futuro diretório repo ou do próprio diretório. Para planejado para repo z:\Main antes svnadmin create

Z:
cd \Main

e, finalmente,

svnadmin create .

Como resultado, criamos um repositório vazio no diretório, mostrado no Windows Explorer com um ícone especial como indicador de conteúdo

Agora, toda vez que esse repositório é necessário, usamos comandos SVN usuais; parte-URL ou parâmetros parecemfile:///Z:/Main

c:\>svn ls file:///Z:/Main
branches/
tags/
trunk/

(Adicionei uma árvore de repositório padrão no repositório).

Vamos dissecar esta URL estranha:

• file:///, como em qualquer URL, significa protocolo de acesso, no nosso caso, o protocolo é especial e possui três, não duas barras
• Z:/Main é o caminho completo para repo com drive e caminho dentro da unidade, todas as barras invertidas do Windows são substituídas por barras clássicas

De qualquer outro ponto, este repositório não possui diferenças de "Big Brothers" com servidores especiais do Subversion

Vamos tentar uma resposta que recomende soluções genéricas e não específicas.

Primeiramente sim, você pode usar o Subversion em um computador autônomo - você pode instalar o servidor localmente ou trabalhar com o arquivo: //

Mas, a menos que haja uma boa razão para você usar o subversion, sugiro que essa não seja a melhor solução para o problema do controle de versão local - principalmente porque falha em uma das coisas que considero essenciais, ou seja, garantindo que você o código fonte está em pelo menos dois lugares (sim, mesmo para coisas pessoais). Portanto, eu sugeriria o uso de um sistema de controle de versão distribuído (DVCS).

Um dos benefícios do DVCS é que, uma vez instaladas as ferramentas, os repositórios ficam independentes em uma pasta e você pode sincronizar o conteúdo entre pastas diferentes contendo o "mesmo" repositório, desde que você tenha acesso no nível do arquivo. Você também tem a opção de conversar com as versões "servidor" desses repositórios (que são hospedados em particular ou estão disponíveis como um serviço). Isso facilita muito a vida, executando tudo localmente.

Existem outras vantagens para o DVCS também.

Como já observei, não acho que você realmente tenha uma solução VCS adequada até que seu código esteja em pelo menos duas máquinas (especificamente dois discos rígidos distintos e, idealmente, em mais de um local - apesar de clonar e pressionar para dizer pen USB ou o armazenamento em "nuvem" (skydrive, dropbox etc.) é outra maneira de funcionar também.

Em termos dos quais DVCS - eu olharia para Mercurial (Hg) e Git e também para Veracity . Eu uso o Mercurial porque ainda é melhor no Windows ...

Se você possui termos de serviços hospedados, eu realmente concordo que há muito para recomendar o github - mas também existem muitas coisas boas sobre bitbucket e Fogbugz / Kiln ... e o mesmo provavelmente acontece com muitos outros serviços que eu não listei (por exemplo, http://beanstalkapp.com/, que foi mencionado ao me passar no twitter hoje cedo)

O Subversion não requer um servidor. Ele usa um repositório centralizado, mas esse repositório pode ser acessado através do método de acesso 'arquivo', o que significa que você só precisa acessar o sistema de arquivos no qual o repositório está armazenado. A maneira mais fácil de configurar isso seria criar uma pasta em algum lugar do seu disco rígido, apontar para o TortoiseSVN (ou uma ferramenta similar) e 'criar repositório aqui'. A partir daí, você pode fazer o que for necessário para inserir seu código no repositório.

No entanto, a longo prazo, você provavelmente estará melhor usando um SCM distribuído, sendo os melhores candidatos o git (curva de aprendizado mais poderosa e íngreme, funciona melhor no * nix) e mercurial (um pouco menos poderoso, fácil de aprender, funciona igualmente bem no windows e * nix). Com isso, sua cópia de trabalho contém o repositório inteiro e você pode criar quantos clones (remoto ou local) desejar. Você pode iniciar localmente e, se decidir hospedar o repositório externamente, basta clonar o repositório local existente no local externo e pode sincronizar nas duas direções a qualquer momento. Melhor ainda, porque cada um dos seus clones contém todo o histórico do projeto, o SCM funciona como um sistema de backup. Com o subversion, se seu servidor morre e você não o fez, seu histórico se foi - com o git,

http://hginit.com/ tem um excelente tutorial sobre como começar com o mercurial.

Existem várias empresas de hospedagem SVN que oferecem uma conta gratuita para um ou dois desenvolvedores e não exigem que seu código seja público. Verifique no gráfico vinculado a taxa de US $ 0, OSS obrigatório = NÃO. Conto nove fornecedores que atendem a esses critérios agora.

Embora você possa hospedar seu próprio repositório com muita facilidade, existem alguns benefícios com o uso de um provedor:

• Você pode acessar seu código de qualquer lugar sem nenhuma configuração extra.

• Manter o código fora do local protege contra falhas no disco rígido, incêndios etc.

• Baixa sobrecarga administrativa.