Controllo versione basato su memoria portatile?

9

Sviluppo progetti personali su due macchine senza l'uso di un server condiviso o una connessione di rete tra i due.

Esistono sistemi di controllo di versione comuni che supportano in modo affidabile l'uso di archiviazione portatile (come un dispositivo flash USB) come archivio condiviso?

version-control

— billpg
fonte

Perché vuoi / hai bisogno di usare l'archiviazione portatile?

— Bernard,

Per spostare il codice tra due macchine nello stesso modo in cui un normale sistema di controllo della versione fa con un server condiviso. (Non ho un server condiviso.)

— billpg

Usavo un set di repository mercuriali su un'unità flash USB per aggiornare gli strumenti di produzione in fabbrica e ha funzionato davvero bene. Potresti anche vedere quando i tecnici sul posto avevano modificato il codice sul computer locale, mentre eri assente, e unire (o rifiutare) le loro modifiche prima di sincronizzare di nuovo le modifiche sull'unità flash.

— Mark Booth,

Qui è già stato detto che SVN supporta l'archiviazione locale e puoi usare USB. Ma preferisco archiviare il suo DB nella mia cartella DropBox privata;) Puoi anche usare molti servizi gratuiti (come assembla o tfs.visualstudio.com)

— Pavel Voronin,

31

Usa un DVCS come Git o Mercurial .

I sistemi di controllo della versione distribuiti non hanno un server centrale condiviso.

Con un DVCS, ogni copia di un repository contiene la cronologia completa - tutto. Ciò significa che, se utilizzato su una chiave USB, tutte le modifiche apportate vengono apportate al repository sulla chiave USB e quando spostate tra i computer conterrà questa cronologia.

— Oded
fonte

9

E se hai usato github, non dovresti nemmeno portare con te un drive USB

— CamelBlues

Grazie. Può essere configurato per utilizzare una memoria portatile come repository?

— billpg

@billpg - Sì. Vive semplicemente in una struttura di directory.

— Oded,

@CamelBlues o bitbucket o kilnhg o probabilmente vari altri che potrebbero essere o non essere appropriati ...

— Murph

3

Ho i miei principali repository Mercurial personali su DropBox. Funziona benissimo e implementa automaticamente il backup (poiché è improbabile che DropBox vada via nello stesso momento in cui perdo tutti i miei computer).

— David Thornley,

7

Oltre a GIT, Mercurial ecc. Sopra suggerito, dai un'occhiata anche a Fossil - Ha i vantaggi che i binari del runtime sono piccoli (circa 1Meg per Windows e Linux), portatili e non richiede installazione. Pertanto, diversamente dagli altri (per quanto ne so), può essere inserito nel dispositivo di archiviazione ed eseguito su qualsiasi macchina a cui è collegata la memoria, senza prima dover installare l'app sulla macchina. Include un Wiki e un sistema di tracciamento di modifiche / difetti con il repository. Ha anche una gui integrata.

Non l'ho usato sul serio (uso principalmente GIT), ma sono rimasto colpito dal suo approccio leggero e l'inclusione di un Wiki e un tracker di difetti lo rendono ideale per piccoli progetti. La mia unica preoccupazione era che alcune delle funzionalità più potenti di GIT potrebbero non essere possibili e, a differenza di GIT, la comunità di utenti non è così grande da trovare facilmente risposte alle domande.

— mattnz
fonte

Sebbene Git prenda il comandamento di Unix per fare una cosa e farlo bene sul serio, puoi avere queste funzionalità in Git attraverso estensioni come ticgit (sistema di ticketing) e gollum (wiki basato su repo).

— Jason Lewis,

@Jason Lewis: Hai ragione, e dato che è open source, puoi semplicemente modificarlo per soddisfare le tue esigenze in ogni caso, quindi GIT (o qualsiasi altro strumento) può essere tutto per chiunque (che può essere disturbato, ha il tempo libero e le risorse per scaricare, installare ed eseguire il debug di tutti i "plug-in". Tutto quello che stavo dicendo è per una soluzione che "Funziona

— immediatamente

1

L'uso di un DCVS è probabilmente una buona idea, ma non è l'unica opzione.

Ho un piccolo repository CVS su una chiavetta USB. Quando voglio accedervi, devo solo usare cvs -d <path>o impostare $CVSROOTil percorso della radice del repository (che ovviamente richiede che la chiavetta sia montata sul sistema).

Se sei già abituato a utilizzare CVS, questo dovrebbe essere praticabile. Lo stesso dovrebbe valere per SVN. Significa solo che il repository centrale si trova sulla chiavetta USB e non è sempre visibile.

Esistono argomenti per l'utilizzo di un DCVS anziché di un CVS in generale. Non penso che questi argomenti siano particolarmente influenzati dal fatto che il repository centrale sia su una chiavetta USB o altrove. Ad esempio, è possibile creare altrettanto facilmente un repository git sulla chiavetta USB.

— Keith Thompson
fonte

1

Di solito non sono un grande fan di DVCS, ma penso che DVCS sarebbe meglio in questo caso. Il problema con VCS non distribuito è che il repository è un singolo punto di errore. Se si trova in un data center climatizzato e viene eseguito regolarmente il backup, questo non è un grosso problema - ma qualcosa come una chiavetta USB si perderà (o calpesterà, o mangerà da un cane o cadrà in un russo bianco) prima o più tardi.

— Mike Baranczak,

1

@MikeBaranczak: buon punto - ma è necessario eseguire regolarmente il backup di qualsiasi cosa su una chiavetta USB, che si tratti di un repository CVS o meno.

— Keith Thompson,

con un sistema distribuito, ogni client ha già una copia completa del repository. Quindi non c'è motivo per una procedura di "backup" separata.

— Mike Baranczak,

1

@MikeBaranczak: Certo, questa è una buona ragione per usare un DCVS. Il mio punto è che la scelta di un DCVS rispetto a un sistema centralizzato non dipende dal fatto che si stia utilizzando o meno una chiavetta USB.

— Keith Thompson,

0

In aggiunta alle altre risposte:

Mentre un DVCS si adatta molto bene a questo problema, tecnicamente potresti anche usare Subversion, se ti senti più a tuo agio con esso. Subversion può utilizzare una directory locale anziché un server centrale. Potresti semplicemente metterlo su una chiavetta USB e usarlo.

Lo svantaggio, rispetto a un DVCS, sarebbe che puoi lavorare solo con Subversion (es. Commit, visualizzare i log ecc.) Mentre la pen drive è collegata. Inoltre, deve sempre essere la stessa pen drive (o almeno un up -data aggiornata), perché con Subversion non dovresti usare più di un repository (che è la parte non distribuita). Quindi, se mai dimentichi la chiavetta USB, non puoi usarla, a differenza di Git o Mercurial.

Nota:

Come spiegato sopra e nei commenti, un DVCS è davvero una soluzione migliore per il tuo problema. Ho citato Subversion solo per completezza, e nel caso abbiate qualche motivo speciale per usare Subversion.

— sleske
fonte

1

Come per la risposta di Keith , il problema con un VCS in una directory locale è che si tratta di un singolo punto di errore. Inoltre, se si passa dalla macchina A alla macchina B ma si lascia la chiavetta collegata alla macchina A, allora è molto meno probabile che ti interessi se si utilizza un DVCS (è sempre possibile unire le modifiche locali in seguito) mentre con un VCS , dovresti tornare alla macchina A, ottenere il drive e tornare alla macchina B prima di poter continuare.

— Mark Booth,

@MarkBooth: non sto sostenendo questa soluzione, volevo solo sottolineare che esiste, per completezza e nel caso in cui OP abbia alcune preferenze speciali per Subversion. Ho modificato la mia risposta per chiarirlo.

— sleske,

Grazie @sleske, concordo sul fatto che una preferenza per svn(o in effetti Cvs) potrebbe pesare a favore dell'utilizzo di tale soluzione, ma nell'interesse della piena divulgazione, dovrebbero essere menzionati anche gli aspetti negativi di tale approccio. Sentiti libero di modificare i punti del mio commento nella tua risposta. Se lo fai, sarei felice di ripulire (eliminare) i miei commenti. * 8 ')

— Mark Booth,

Non sono sicuro di ciò che aggiunge questa risposta che non avevo già detto nel mio.

— Keith Thompson,

1

@KeithThompson: aggiunge le informazioni che SVN può utilizzare una directory locale anziché un server centrale. Ciò è spiegato nei documenti SVN, ma poiché la maggior parte delle persone utilizza SVN tramite un server centrale, potrebbe non essere ovvio che SVN non richiede un server.

— sleske,