Controle de versão baseado em armazenamento portátil?

9

Desenvolvo projetos pessoais em duas máquinas sem o uso de um servidor compartilhado ou uma conexão de rede entre as duas.

Algum sistema de controle de versão comum oferece suporte confiável ao uso de armazenamento portátil (como um dispositivo flash USB) como repositório compartilhado?

version-control

— billpg
fonte

Por que você deseja / precisa usar armazenamento portátil?

— Bernard

Mover código entre duas máquinas da mesma maneira que um sistema de controle de versão normal faz com um servidor compartilhado. (Eu não tenho um servidor compartilhado.)

— billpg

Eu costumava usar um conjunto de repositórios mercuriais em uma unidade flash USB para atualizar as ferramentas de fabricação na fábrica e funcionava muito bem. Você pode até ver quando os técnicos no local estavam modificando o código na máquina local enquanto estava ausente e mesclar (ou rejeitar) as alterações antes de sincronizar as alterações na unidade flash.

— Mark Booth

Já foi dito aqui que o SVN suporta armazenamento local e você pode usar o usb. Mas eu prefiro armazená-lo do DB na minha pasta DropBox privado;) Você também pode usar muitos serviços gratuitos (como Assembla ou tfs.visualstudio.com)

— Pavel Voronin

31

Use um DVCS como Git ou Mercurial .

Os sistemas de controle de versão distribuído não possuem um servidor central compartilhado.

Com um DVCS, cada cópia de um repositório contém o histórico completo - tudo. Isso significa que, quando usadas em uma chave USB, quaisquer alterações feitas são feitas no repositório na chave USB e, quando movidas entre computadores, manterão esse histórico.

— Oded
fonte

9

E se você usou github, você nem sequer tem que levar em torno de um drive USB

— CamelBlues

Obrigado. Pode ser configurado para usar um armazenamento portátil como repositório?

— billpg

@billpg - Sim. Ele simplesmente vive em uma estrutura de diretórios.

— Oded

@CamelBlues ou bitbucket ou kilnhg ou, provavelmente, vários outros que podem ou não ser apropriado ...

— Murph

3

Eu tenho meus principais repositórios pessoais do Mercurial no DropBox. Funciona muito bem e implementa automaticamente o backup (já que é improvável que o DropBox desapareça ao mesmo tempo em que perco todos os meus computadores).

— David Thornley

7

Além do GIT, o Mercurial etc sugerido acima, também dê uma olhada no Fossil - Ele tem as vantagens de que os binários de tempo de execução são pequenos (1Meg ou mais para Windows e Linux), instalação portátil e zero. Portanto, diferentemente dos outros (que eu saiba), ele pode ser colocado no dispositivo de armazenamento e executado em qualquer máquina na qual o armazenamento esteja conectado, sem a necessidade de instalar o aplicativo na máquina. Ele inclui um Wiki e um sistema de rastreamento de alterações / defeitos no repositório. Ele também possui uma interface gráfica.

Eu não o usei a sério (eu uso principalmente o GIT), mas fiquei impressionado com sua abordagem leve e a inclusão de um Wiki e rastreador de defeitos o torna ideal para pequenos projetos. Minha única preocupação era que alguns dos recursos mais poderosos do GIT não fossem possíveis e, diferentemente do GIT, a comunidade de usuários não é tão grande que é fácil encontrar respostas para as perguntas.

— mattnz
fonte

Embora o Git leve o mandamento do Unix para fazer uma coisa e faça muito bem a sério, você pode ter esses recursos no Git através de extensões como ticgit (sistema de bilhética) e gollum (wiki baseado em repositório).

— Jason Lewis

@ Jason Lewis: Você está correto e, como é de código aberto, pode modificá-lo para atender aos seus requisitos de qualquer maneira, para que o GIT (ou qualquer outra ferramenta) possa ser tudo para qualquer um (que pode ser incomodado, tem tempo e recursos livres) para download, instalar e depurar todos os "plugins" Tudo o que eu estava dizendo é uma solução que "simplesmente funciona fora da caixa", vale a pena Fossil considerando..

— mattnz

1

Usar um DCVS provavelmente é uma boa ideia, mas não é a única opção.

Eu tenho um pequeno repositório CVS em um pen drive USB. Quando quero acessá-lo, só preciso usar cvs -d <path>ou definir $CVSROOTo caminho da raiz do repositório (o que, obviamente, exige que o pen drive seja montado no sistema).

Se você já está acostumado a usar o CVS, isso deve ser viável. O mesmo deve se aplicar ao SVN. Significa apenas que seu repositório central está no pen drive e nem sempre é visível.

Existem argumentos para usar um DCVS em vez do CVS em geral. Não acho que esses argumentos sejam particularmente afetados pelo fato de o repositório central estar em um pen drive ou em outro lugar. Por exemplo, você poderia facilmente criar um repositório git no pen drive.

— Keith Thompson
fonte

11

Normalmente não sou um grande fã do DVCS, mas acho que o DVCS seria melhor nesse caso. O problema com VCS não distribuído é que o repositório é um ponto único de falha. Se ele estiver em um data center com controle climático e for feito backup regularmente, isso não é grande coisa - mas algo como um pen drive será perdido (ou pisado, ou comido por um cachorro ou abandonado em um russo branco) mais cedo ou mais tarde.

— precisa saber é o seguinte

11

@MikeBaranczak: Bom ponto - mas tudo em um pen drive deve ser feito regularmente, seja um repositório CVS ou não.

— perfil completo de Keith Thompson

com um sistema distribuído, cada cliente já possui uma cópia completa do repositório. Portanto, não há razão para um procedimento de "backup" separado.

— Mike Baranczak

11

@MikeBaranczak: Claro, essa é uma boa razão para usar um DCVS. Meu argumento é que a escolha de um DCVS versus um sistema centralizado não depende de você estar usando um pen drive ou não.

— perfil completo de Keith Thompson

0

Como complemento às outras respostas:

Enquanto um DVCS se encaixa muito bem nesse problema, você também pode usar o Subversion tecnicamente, se sentir-se mais confortável com ele. O Subversion pode usar um diretório local em vez de um servidor central. Você pode colocar isso em um pen drive e usá-lo.

A desvantagem, comparada a um DVCS, seria que você só pode trabalhar com o Subversion (por exemplo, confirmar, visualizar logs etc.) enquanto o pen drive estiver conectado. Além disso, deve sempre ser o mesmo pen drive (ou pelo menos um até a data), porque com o Subversion você não deve usar mais de um repositório (essa é a parte não distribuída). Portanto, se você esquecer seu pen drive, não poderá usá-lo, ao contrário do Git ou do Mercurial.

Nota:

Como explicado acima, e nos comentários, um DVCS é realmente um ajuste melhor para o seu problema. Eu apenas mencionei o Subversion por questões de integridade, e caso você tenha algum motivo especial para usar o Subversion.

— sleske
fonte

11

Como na resposta de Keith , o problema com um VCS em um diretório local é que ele é um único ponto de falha. Além disso, se você passar da máquina A para a máquina B, mas deixar o pen drive conectado à máquina A, será muito menos provável que você se importe se estiver usando um DVCS (você sempre poderá mesclar suas alterações locais mais tarde) enquanto com um VCS , você teria que voltar para a máquina A, pegar a unidade e voltar para a máquina B antes de continuar.

— Mark Booth

@ MarkBooth: Eu não estou defendendo esta solução, só quero salientar que ela existe, por uma questão de integridade e caso o OP tenha algumas preferências especiais para o Subversion. Eu editei minha resposta para deixar isso claro.

— sleske

Obrigado @sleske, eu concordo que uma preferência por svn(ou mesmo Cvs) poderia pesar a favor do uso dessa solução, mas, no interesse da divulgação completa, as desvantagens dessa abordagem também devem ser mencionadas. Sinta-se livre para editar os pontos do meu comentário na sua resposta. Se o fizer, ficaria feliz em limpar (excluir) meus comentários. * 8 ')

— Mark Booth

Não sei ao certo o que essa resposta acrescenta que eu ainda não disse na minha.

— perfil completo de Keith Thompson

11

@ KeithThompson: Adiciona as informações de que o SVN pode usar um diretório local em vez de um servidor central. Isso é explicado nos documentos do SVN, mas como a maioria das pessoas usa o SVN por meio de um servidor central, pode não ser óbvio que o SVN não exija um servidor.

— sleske