controllo di versione continua

Question

Non ho visto un sistema di controllo versione continua -. Uno che salva le modifiche nel codice come li avete sviluppato, invece di aspettare per un controllo ufficiale in Le modifiche sarebbero salvati come 'non controllato in' ovviamente, ma sarebbero salvati via per il backup, e la visualizzazione da altri prima che realmente fatto la registrazione ufficiale.

Non ho visto questo, e mi chiedo se, o qualcosa di simile, esiste, e le ragioni per cui potrebbe o non potrebbe essere una buona idea.

In questo momento i programmatori pensano di controllo del codice sorgente, come l'integrazione di pacchetti di codice, ma perché non fare i pacchetti più piccoli e integrare continuamente?

-Adam

Answer 1

  

In questo momento i programmatori pensano di controllo del codice sorgente, come l'integrazione di pacchetti di codice, ma perché non fare i pacchetti più piccoli e integrare continuamente?

Direi DVCS stanno già praticamente facendo adesso, non perché sono decentrate, ma perché commettere è così molto più veloce .. Con git mi impegnano molto più spesso che con SVN .. E rende anche più semplice per commettere "pezzi "o di codice specifico (usando git add -i o git gui), ed è generalmente molto più concentrato sul tracciamento di linee di codice, piuttosto che file completi (come '' VCS tradizionale' come Subversion)

Inoltre, il modo in cui funziona git intrinsecamente mezzi, come lei ha detto, "i cambiamenti sarebbero stati salvati come 'non controllato in' ovviamente" .. Quando si impegnano, i cambiamenti sono locali, quindi li spinge alla macchina remota con un comando separato .. si potrebbe commettere ogni volta che si salva, poi li rebase in un singolo commit se si voleva.

Per quanto riguarda uno strumento che fa "controllo di versione continua", si potrebbe fare questo semplicemente con uno script di shell, qualcosa di simile ..

while [ 1 ]; do
   git add -a && git commit -m "Autocommit at $(date)";
   sleep 10;
done

C'è uno script, CACM ( github ), che fa qualcosa di simile

  

[CACM] Orologi una directory specifica, e impegna tutte le modifiche a un repository Git standalone.

     

Per usare basta fare:

     

cacm --repo dir_of_git_repo --watch dir_to_watch

Io non sono sicuro perché ci si vuole fare così .. ho trovato una delle cose più utili sull'utilizzo di un VCS è la diff di quello che ho cambiato (dall'ultima commit). Sembra avere costanti commit / automatizzati sarebbe solo rumore ..

Inoltre, il "e" Editor di testo ha una caratteristica interessante, visualizza la cronologia degli annullamenti, con ramificazione . C'è un blog-post su di esso con screenshot.

Answer 2

Il processo di costante salvataggio automatico non è un compito per un sistema di versione, ma per l'editor. Quando si vede una nuova versione del sistema di versione, dovrebbe rappresentare un cambiamento significativo dalle altre versioni, non ogni parola halftyped.

Answer 3

Eclipse ha una funzione chiamata 'storia locale' che fa esattamente questo. Manterrà una copia dei file di origine tra i salvataggi. Si tiene anche traccia delle cartelle eliminate per voi. Ha salvato il mio culo un certo numero di volte. Si può vedere Storia locale come il controllo della versione a basso livello che succede solo sul computer locale. Rovescio della medaglia è, naturalmente, quando si lavora su una macchina diversa, si avrà una diversa storia locale.

Answer 4

è possibile utilizzare un sistema di controllo di distribuire la versione, come Bazar , git , Mercurial.  allora si può impegnarsi a livello locale.

Answer 5

Ho visto alcuni plugin basati inotify per varie DVCS, tuttavia questi possono essere solo, ma così intelligente. In realtà, la cosa ideale da fare è memorizzare il repository su un file system copy-on-write, in modo che questi granulari frequente (e immutabili) versioni dei file vengono tenuti al di fuori della DVCS.

Come altri hanno già detto, preferisco fare molti piccoli impegni. Con un DVCS, non dovete preoccuparvi di rompere il ramo tronco o maestro, spingere solo dopo il gioco è fatto .. nessuna preoccupazione per le revisioni tossici come modificare i file.

Su Linux, io uso ext3cow dove riporre i miei repository HG / Git. Questo mi dà il tipo di funzionalità che si descrive. Triste a dirsi, non so di nulla di simile che è portatile al di là di Linux. Forse qualche squadra pazza si presenti con uno in Python.

Questa domanda ha messo a punto diverse volte prima (anche se ognuno in un contesto diverso), quindi sicuramente la necessità di qualcosa di simile ext3cow (ma portatile) è evidente. Eppure, non vorrei che gonfiano in un DVCS sé, soprattutto su grandi alberi.

Credo che si ha realmente bisogno di chiedere per questo dal file system, non il DVCS.

Answer 6

Se non si desidera effettuare il check in tutti il cambiamento. Si vuole controllare in set atomiche di cambiamenti che possono lavorare insieme. Se non si desidera aggiungere un parametro a un metodo e salvare, averlo registrato (e una corsa CI build), quindi hanno la pausa costruire perché non avete ancora aggiornato le chiamate al metodo.

Answer 7

Vuoi dire qualcosa di simile a Subversion autoversionamento ?

Disclaimer:. Non sto dicendo autoversionamento è una buona idea per lo sviluppo, o che io personalmente farlo, ma esiste la tecnologia

Answer 8

Si potrebbe commettere ogni linea, o un personaggio con un DVCS come git se si voleva. In generale, penso che sia una grande idea di impegnarsi il più spesso possibile, quando si utilizza un DVCS, per rendere più facile la caccia problemi con strumenti come git bisect. Se si voleva l'effetto che descrivere, si potrebbe sceneggiatura vostro editor di scelta di impegnarsi in ogni salvare ... In pratica, anche se mi piacerebbe pensare che sarebbe un po 'troppo.

Answer 9

Alcune persone sarebbe messa a punto di un ramo di sviluppo per questo scopo e hanno gli sviluppatori commettono i loro cambiamenti mentre lavorano prima di fondersi in un ramo livello di garanzia della qualità. Si potrebbe anche avere uno sviluppatore di fare grandi cambiamenti lavorano nel suo / la sua propria filiale prima di commettere e la fusione quelle modifiche nel ramo di sviluppo principale. Così, ramificazione può affrontare questo.

Answer 10

Credo che Eclipse fa, o usato per fare qualcosa di simile ad ogni salvataggio. Mi ha salvato un paio di volte in cui il mio codice finì per essere fatto a pezzi durante il tentativo di individuare un bug.

Answer 11

Ecco un approccio diverso. Quasi ogni giorno corro a situazioni in cui qualcosa smette di funzionare e non so perché. Ho riavvolgere un paio di minuti e verificare quali sono state apportate modifiche e quali file. Quindi sono d'accordo sulla necessità di un controllo di versione continouos.

Allo stesso tempo è vero che non si desidera per il check-migliaia di piccole modifiche ogni giorno nel vostro repository.

Ok, quindi questo è quello che si fa. È possibile utilizzare entrambi, ma non li mescolare. Il vostro controllo del codice sorgente deve essere utilizzato da tutta la squadra e il check-in a quello di tanto in tanto. Allo stesso tempo, si esegue alcuni software versione fascicolo personale locale che consente di risparmiare ogni piccolo cambiamento e rende facile per voi di utilizzare effettivamente le informazioni.

Questo è tutto. Io uso Storia Explorer dal momento che ha contribuito a sviluppare, ma ci sono altri là fuori anche.

Answer 12

Potreste essere interessati a sistema di controllo di versione continua sviluppato da JetBrains. Non è pubblico ancora, ma mostrano alcune caratteristiche di esso nel mio intervento alla JetBrainsDay a Malmo: http : //new.livestream.com/jetbrains/jetbrainsday1/videos/29348962

Answer 13

Dan menzionato , IBM Visual Age IDE mantenuto tutte le versioni è stato salvato di un file di codice sorgente. Questo approccio non si limita alla IDE, tuttavia; il rel="nofollow sistema operativo VMS dicembre ha adottato un approccio simile con la sua di versione file system. Nel VMS, il nome completo di ogni file incluso un numero di versione, e ogni volta è stato salvato un file, una nuova copia è stato creato con un numero di versione di uno rispetto al precedente numero più alto.

Nessuno dei due approcci abbastanza soddisfa il controllo di versione, come lo conosciamo oggi, in quanto entrambi mancano di ramificazione (o, se è per questo, tutte le caratteristiche progettate in particolare per facilitare più persone lavorano sullo stesso file sorgente). Ma, entrambi servono allo scopo di di backup contro l'errore umano, che per me è l'aspetto più utile di controllo della versione.

Answer 14

Avere più di qualche anno di esperienza di programmazione in Java, ricordo ancora (con nostalgia) nuovo approccio che Visual Age ha portato al processo di sviluppo. Visual Age ha avuto un approccio non-file di codice sorgente. Codice è stato memorizzato nel database relazionale. Faresti generalmente lavora su una vista che mostra un unico metodo. Hai anche avuto una visione completa di file, ma non lo uso più di tanto.

Per quanto riguarda il controllo di versione, si genererebbe una versione con ogni salvataggio. Si potrebbe punto di controllo in modo esplicito un metodo, classe / interfaccia, pacchetto o l'intero progetto con un numero di versione / nome. E 'consentito anche un maggiore controllo a grana fine della sorgente sul livello di metodo. Una volta ho iniziato a lavorare con Eclipse, mentre ha ereditato molte caratteristiche da Visual Age, e oggi ha funzione Cronologia che salva localmente tutti “salva” del codice, non ho potuto fare a meno ho fatto un passo indietro.

Answer 15

ClearCase ha il concetto di un visualizzazione dinamica . Su Windows, la visualizzazione di sviluppo mostra come un'unità mappata, ma le modifiche del codice vengono memorizzate lato server, non appena si preme salvare. E 'questo quello che stai cercando?

Ci sono, come ci si aspetterebbe, compromessi con lavorare in questo modo, così come la risposta Si s '< a href = "https://stackoverflow.com/questions/688546/continuous-version-control/688554#688554"> sopra , questa non è una raccomandazione ...

Answer 16

Come su VESTA?

http://www.vestasys.org/