DVCS e perdita di dati?

Question

Dopo quasi due anni di utilizzo di DVCS, sembra che un difetto "intrinseco" sia la perdita accidentale dei dati: ho perso il codice che non viene spinto, e conosco anche altre persone che lo hanno.

Posso vedere alcuni motivi per questo: la duplicazione dei dati fuori sito (cioè "i commit devono andare su un host remoto") non è integrata, il repository risiede nella stessa directory del codice e della nozione di "hack" fino a che non hai qualcosa da rilasciare "è prevalente ... Ma questo è oltre il punto.

Sono curioso di sapere: hai riscontrato perdite di dati relative al DVCS? O stai usando DVCS senza problemi? E, collegato, a parte "ricorda di spingere spesso", c'è qualcosa che può essere fatto per minimizzare il rischio?

Answer 1

Ho perso più dati dal clobbering di modifiche non memorizzate in un VCS centralizzato, e poi ho deciso che volevo davvero che fossero, rispetto a qualsiasi cosa che ho fatto con un DVCS. In parte è che utilizzo CVS da quasi un decennio e git da meno di un anno, quindi ho avuto molte più opportunità di mettermi nei guai con il modello centralizzato, ma differenze nelle proprietà del flusso di lavoro tra due modelli sono anche i principali fattori che contribuiscono.

È interessante notare che la maggior parte dei motivi si riduce a "PERCHÉ è più facile scartare i dati, è più probabile che continui finché non sono sicuro di non volerlo". (L'unica differenza tra scartare i dati e perderli è che intendevi disfarsene.) Il fattore di contribuzione più grande è probabilmente una stranezza delle mie abitudini nel flusso di lavoro: la mia "copia di lavoro" quando utilizzo un DVCS è spesso distribuita su più copie su più computer, quindi la corruzione o la perdita in un singolo repository o addirittura la perdita di dati catastrofici sul computer su cui stavo lavorando è meno probabile che distrugga l'unica copia dei dati. (Essere in grado di fare questo è una grande vittoria del modello distribuito rispetto a quelli centralizzati - quando ogni commit diventa una parte permanente del repository, la barriera psicologica per copiare i tentativi di modifica è molto più alta.)

Per quanto riguarda minimizzando i rischi, è possibile sviluppare abitudini che li riducano al minimo, ma è necessario sviluppare tali abitudini. Due principi generali là:

• dati non esiste fino a quando non ci sono più copie di esso in diversi luoghi . Ci sono abitudini del flusso di lavoro che vi darà più copie gratis - f'rexample, se si lavora in due luoghi diversi, avrai un motivo per spingere ad un percorso comune al termine di ogni sessione di lavoro, anche se non è pronto per la pubblicazione.
• Non provare a fare nulla di intelligente, stupido, o oltre la tua zona di comfort con l'unico riferimento a un commit che potresti voler mantenere. Creare un tag temporaneo che è possibile ripristinare, o creare un ramo temporaneo per fare le operazioni su . (Reflog di git permette recuperare i vecchi riferimenti dopo il fatto ; sarei sorpreso se altri DVCSs hanno funzionalità simili codifica Quindi manuale non può essere necessaria, ma è spesso più conveniente comunque..

Answer 2

Ho perso i dati da un DVCS, sia a causa della rimozione dell'albero insieme al repository (non ricordando che aveva informazioni importanti), sia a causa di errori nell'utilizzo della riga di comando DVCS (git, nel caso specifico): alcune operazioni che intendevano ripristinare una modifica che ho apportato in realtà cancellavano un certo numero di revisioni già impegnate dal repository.

Answer 3

C'è una tensione intrinseca tra l'essere distribuiti e assicurarsi che ogni cosa sia "salvata" (con l'ipotesi di fondo che salva significa essere salvati da qualche altra parte).

IMO, questo è solo un problema reale se si lavora su più computer contemporaneamente sulla stessa linea di lavoro (o più esattamente diversi repository: spesso ho bisogno di condividere le modifiche tra più VM sullo stesso computer per esempio). In questo caso, un flusso di lavoro "centralizzato" sarebbe l'ideale: si configurerebbe un server temporaneo e, su alcuni rami, si utilizzerà un flusso di lavoro centralizzato. Nessuno degli attuali DVCS che conosco (git/bzr/hg) supporta questo bene. Sarebbe comunque una buona caratteristica avere.