Mercurial (e, credo Git) con Dropbox: qualche inconveniente?

Question

Possiedo un repository Mercurial per un progetto personale e ho archiviato il repository principale nel mio Dropbox da alcune settimane (qualcosa che segue lo this line e ho capito che è anche possible with git).

L'idea è che serva sia come modo di lavorare con più macchine sia come backup remoto. Clonato il repository e lavoro sulla copia non Dropbox, e spingo gli aggiornamenti solo una volta ogni tanto, nello stesso modo in cui, suppongo, funzionerei con Bitbucket.

Riesci a pensare a qualche inconveniente di questa idea, rispetto all'uso di hosting dedicato (BitBucket nel caso di Mercurial)? So che Bitbucket ha account gratuiti per utenti singoli, il che è fantastico, ma sono limitati a 150M, che non è un enorme.

In particolare, è possibile che il processo di sincronizzazione di Dropbox danneggi il repository? Ho dovuto eseguire hg recuperare una volta sul repository principale, ma potrebbe non essere correlato (e comunque recuperato felicemente). Qualcuno ha una brutta esperienza con l'idea? Qualcuno ha una buona esperienza e può alleviare le mie preoccupazioni? Qualcuno ha un'opinione basata su una migliore comprensione degli interni di queste cose?

modifica: ho aggiunto alcuni chiarimenti alle domande. Sono in corsivo.

Answer 1

Vorrei sconsigliarlo per le ragioni sopra esposte, ma più strenuamente affermato. Sia mercurial che git hanno i loro protocolli per spostare i changeset tra i repository. Questi protocolli sono ottimizzati/costruiti per:

• efficienza
• coerenza (non si può tirare da un pronti contro termine in uno stato di semi-aggiornato)
• ganci/trigger di - fare le cose sul push/pull tra cui la qualità (senza schede permessi, ecc) filtri

Quando si lascia solo una sincronizzazione directory gestire la tenuta del .hg (o .git) le directory in sincronia poi durante la sincronizzazione che hai un negozio a distanza che è in uno stato incoerente e non lo sa.

Inoltre, sia hg che git hanno una separazione di ciò che è solo locale e cosa è remoto-ok nello stato del disco. Sanno quali informazioni condividere (esempio: changeset attivati) e cosa no (esempio: revisione genitore attuale, locale della directory di lavoro).

In altre risposte la gente dice "probabilmente starai bene" o "Non ho mai avuto un problema" e probabilmente è vero, ma non è garantito vero e il controllo di revisione non è un luogo in cui giocare probabilità. Utilizza il protocollo di sincronizzazione appropriato, migliore, più sicuro, più efficiente e più completo per il tuo sistema di controllo sorgente.

Answer 2

Mi aspetterei problemi se si tenta di accedere al repository nel mezzo della sincronizzazione. Sembra anche essere un po 'sovraccarico. Non hai veramente bisogno di sincronizzare le cose che sincronizzi. Non ho idea di come dropbox gestisca i conflitti, ma dubito che possa farlo in modo scm-aware.

Answer 3

Suppongo che probabilmente funzionerebbe bene per progetti personali su una o due macchine, ma in realtà vorrete usare l'hosting professionale per progetti multi-membri.

Ho utilizzato personalmente BitBucket per un po 'di tempo e sono stato piuttosto soddisfatto ... puoi anche avere un progetto privato sull'account gratuito.

Answer 4

+1 per bitbucket. È gratuito e ottieni un singolo repository privato con quell'account gratuito (a differenza di Github).

Lo svantaggio con la soluzione solo su Dropbox è che se si svita qualcosa nel repository sul proprio computer, tale errore verrà copiato su bitbucket e replicato in ogni altro punto in cui è installato il dropbox. Dropbox è molto veloce, quindi non sarai in grado di impedire che accada in tempo per evitare problemi.

Si perde la capacità di disaccoppiare apportare modifiche al repository con la pubblicazione di tali modifiche.

Io uso dropbox per ospitare un paio di repository che utilizzo sia su macchine domestiche che da lavoro, ma quelle non sono le uniche copie di questi repository. C'è anche un repository bitbucket (così come altre persone che ne hanno cloni).

Answer 5

Ho utilizzato Dropbox con git per progetti personali da un po 'di tempo e non ho ancora avuto un singolo problema. Sebbene, a volte devi aspettare che Dropbox si sincronizzi. I penso che questo può causare problemi minori se ci sono più persone che lavorano sullo stesso progetto, ma per progetti personali, trovo Dropbox ancora migliore di GitHub, se non altro per il fatto che spingere/tirare è più veloce.

Per quanto riguarda il push/pull mid-sync, questo molto probabilmente causerà problemi e potrebbe anche danneggiare il repository, ma se sei l'unico che lavora al progetto, allora sai esattamente quando Dropbox si sincronizzerà.

Answer 6

Ho riscontrato problemi con i repository Dropbox danneggiati. Non succede sempre, ma il fatto che sia successo più di una volta significa che smetterò di utilizzare Dropbox per questo scopo.

Detto questo, Dropbox è sicuramente più economico di un vero hosting, quindi se conservi i backup potresti trovarlo accettabile per i progetti personali.

Answer 7

Non suggerirei di utilizzare dropbox con mercurial, poiché spesso vedo file in conflitto tra i miei client Mac e Windows. Soprattutto l'annullamento è interessato, ma ho avuto anche conflitti con altri file.

saluti Mirko

Answer 8

Io lo utilizzo con Bazaar in questo momento in tutto 3 macchine. Tuttavia, io sono lo sviluppatore solitario in uno qualsiasi dei rami.

Ho utilizzato il comando init-repo --no-trees per creare il repository.

Answer 9

Anche io uso Dropbox con Hg senza problemi fino ad ora. Troppo tardi mi sono reso conto che hg non segnala la corruzione durante i checkin di routine, solo quando si tenta di usare il repository per davvero (la peggiore di tutte le situazioni, dal momento che non si sa se qualcosa è rotto fino a quando non ne hai davvero bisogno).

Non è chiaro se il danneggiamento è spontaneo o causato dall'accesso al repository con client Mac, Windows e Linux (io uso tutti e tre in momenti diversi). Ma ho visto almeno un caso di corruzione che si verificava quando solo il Mac era attivo, quindi poteva benissimo essere Dropbox.

Se si decide di vivere in modo pericoloso, eseguire "hg verify" (o "git verify" regolarmente per sollevare sporco.

Answer 10

Per coloro che preferiscono utilizzare Dropbox su bitbucket/GitHub, ecco quello che faccio per evitare la corruzione dal processo di sincronizzazione a 2 vie di servizi di backup su cloud:

cartella My codice locale è c:\code & cartella di backup è c:\Dropbox . All'interno della cartella Dropbox, ho un contenitore di file crittografato truecrypt (la sua dimensione è sufficientemente maggiore della mia cartella di codice). Durante il giorno applico regolarmente modifiche al mio repository Git/Mercurial locale. Tuttavia alla fine della giornata, esco da Dropbox & per montare il contenitore di file TrueCrypt. Sposto le modifiche in un repository nudo nel contenitore dei file, smontalo & riavvia Dropbox.

In questo modo, posso tranquillamente utilizzare un servizio cloud per servire come backup del mio repository DVCS. Se il contenitore dei file è in uso, Dropbox attenderà che venga smontato, quindi spero che non ci siano cambiamenti di corruzione. Tuttavia, se ottengo in qualche modo una copia conflittuale del contenitore dei file, posso facilmente montare entrambe le copie e confrontare i changeset.