Che cosa è una spiegazione di una frase di come funziona AccuRev?

Question

Capisco Git, Subversion, CVS e una miriade di altri sistemi di controllo del codice sorgente.

Ho iniziato usando AccuRev e mi confonde.

Credo che ho bisogno di formare un modello mentale che si riferisce ad altri SCM di. Idealmente relativa a git perché ho capito git il migliore.

I spiegherebbe git come "un grafo orientato di commit in cui un commit è un diff, un genitore (o genitori) hash, e un hash di se stesso." Si può facilmente passare da lì a spiegare concetti come rebase e ciò che si fonde in realtà sono, fast-forward vs. fonde effettivi e così via. Ho trovato facile insegnare ai nuovi utenti complessi concetti git in circa 15-20 minuti.

Mi piacerebbe davvero capire AccuRev a quel livello. Quindi ...

Qual è la volta sentenza astrazione di come funziona AccuRev che rende possibile spiegare come si comporta?

Alcuni esempi di domande vorrei il mio modello mentale di risposta:

• Che cosa accade quando "Continuo" alcuni file e poi "promuovere la" loro?
• Che cosa succede se io non promuovo gli stessi file come ho appena tenuto?
• Perché la storia a volte si mis-attribuita quando in conflitto non (anche noto come sovrapposizione) gli aggiornamenti avvengono? Questo, in particolare, ricorda una modalità di guasto di Subversion che, dalle spiegazioni di base che ho sentito, non credo dovrebbe esistere con AccuRev.
• Perché diff contiene quasi mai quello che loro mi aspetto di? Credo che ciò che di accadere è che diff contro di base mi mostra il diff contro corrente (in movimento) flusso di genitore, ma quello che voglio è solo quello di vedere i cambiamenti che ho fatto da quando ho aggiornato l'ultima volta.

Answer 1

Avviso: Il sistema di controllo del codice sorgente Capisco migliore è SVN. In modo che i colori mio uso di termini come pronti contro termine, cassa, ecc Inoltre, io uso AccuRev su base giornaliera, ma tendono a non allontanarsi troppo dai concetti fondamentali che mi sento di avere una solida conoscenza.

Una frase (con un asterisco): AccuRev è un repository di tempo ordinato che mantiene una cronologia delle revisioni dei file modificati per ogni flusso / area di lavoro, e permette di sviluppare diverse versioni del codice ( nei corsi d'acqua), mentre ciascun flusso è trasparente aggiornato con il codice di base dal suo genitore e bambino * stream.

(*) Un flusso viene aggiornato da un flusso figlio solo una volta un flusso di bambino favorisce i cambiamenti nel flusso genitore.

Il principale vantaggio di AccuRev è la capacità di mantenere diverse versioni di codice facilmente. Se si vuole cogliere, io non cercherei astrazioni veloci o termini ridefinito nel linguaggio si ha familiarità con. Mi piacerebbe cercare esempi e una spiegazione delicata di termini che si presentano. Purtroppo, so solo quello che ho bisogno di sapere, ma ho deciso di dargli un colpo ...

(ne parlerò più aree di lavoro più tardi. Non preoccupatevi di loro a questo punto.)

Quando si crea un flusso parented off di un altro, è come avete fatto un ramo SVN per creare il flusso di bambino, ma il (meraviglioso) differenza è che unioni SVN sono presi cura di per voi ogni volta che si aggiorna il padre o figlio flusso (o si viene avvisati quando esiste un conflitto ed è necessario risolvere manualmente).

Diciamo che si inizia con un flusso, CompanyStream. La vostra base di codice è gestito da quella corrente, e ha una storia di modifiche apportate ai file. Quindi si decide di creare due flussi bambino al di sotto che, ChildStream1, ChildStream2. Tutte le modifiche apportate ai file in CompanyStream saranno trickle down per entrambi i flussi bambino, così hanno sempre l'ultimo codice che hanno ereditato da CompanyStream. (Eredità dei cambiamenti di revisione è un concetto di base in AccuRev.) Nel frattempo, si sta facendo specifico lo sviluppo di un unico vendor in ChildStream1, e cambia propri di un altro fornitore nel ChildStream2. È selettivamente può decidere quale codice ChildStream1 e 2 ottenere una promozione al CompanyStream, ma le modifiche apportate in CompanyStream dovrebbero essere cose che si desidera visualizzare in entrambi i flussi bambino. Se si promuove codice ChildStream1 in CompanyStream, quindi tali modifiche appariranno nella ChildStream2 volta che lo fa un aggiornamento (perché ancora una volta, eredita CompanyStream)

La visualizzazione flusso sarebbe simile a questa:

CompanyStream -
| - ChildStream1
| - ChildStream2

AccuRev Overlap = Un file in un flusso genitore è stato modificato dopo che hai aggiornato il tuo flusso. Visualizza il flusso genitore ad essere sopra di voi (che è come sarà visualizzata nel client), e che ha progredito flusso orizzontale in modo che si sovrapponga il punto nel tempo in cui ti trovi.

mappatura rapida di SVN per concetti AccuRev:
SVN arrivo - Promuovere
SVN Checkout - Anchor (ancoraggio qualcosa lo rende un WIP - Work In Progress)
SVN Update - Aggiornamento

AccuRev aree di lavoro

Non ho ancora citato spazi di lavoro. Uno spazio di lavoro rappresenta il codice sul disco rigido. Uno spazio di lavoro è simile a un torrente in quanto può avere una storia, e si può tenere traccia delle modifiche apportate. (Questo è ciò che una Fortezza fa -.. Memorizza un'istantanea dei file specificati durante quell'operazione Tenere nella storia del vostro spazio di lavoro È possibile ripristinare quelle istantanee dei file in qualsiasi momento Di conseguenza, uno spazio di lavoro può anche essere visto come il tuo proprio personale, corso d'acqua privato, che è un record di modifiche apportate al codice all'interno.)

Streams sono concetti astratti che rappresentano i cambiamenti di revisione, e una storia di quanto è successo. Corsi d'acqua e aree di lavoro ereditano il codice dai loro genitori streams. A differenza di corsi d'acqua, tuttavia, le aree di lavoro non possono avere flussi di bambino o aree di lavoro del bambino. Le aree di lavoro sono come le foglie su un albero; flussi sono come rami.

• Che cosa accade quando "Continuo" alcuni file e poi "promuovere la" loro?

È promuovere ad un ruscello. You Keep a un'area di lavoro. cambiamenti promossi sono visibili a tutti coloro che possono vedere il fiume. cambiamenti Kept sono visibili solo a te, il proprietario dello spazio di lavoro.

I fascicoli tenuti avrà istantanee nell'area di lavoro (nel caso vi capitasse di voler tornare a loro). I file promossi avranno istantanee (si fa per dire) nel flusso li promosso a. La grande differenza è che i cambiamenti promossi saranno trickle down a tutti i corsi d'acqua o aree di lavoro che ereditano tale flusso.

• Che cosa succede se io non promuovo gli stessi file come ho appena tenuto?

Poi sarà solo nell'area di lavoro. Inoltre, credo che quando si fa un promuovere, AccuRev fa un mastio prima (in modo da avere una registrazione della modifica di file sia in spazio di lavoro e il flusso a cui si sta promuovendo).

• Perché la storia a volte si mis-attribuita quando in conflitto non (anche noto come sovrapposizione) gli aggiornamenti avvengono? Questo, in particolare, ricorda una modalità di guasto di Subversion che, dalle spiegazioni di base che ho sentito, non credo dovrebbe esistere con AccuRev.

Può fare un esempio? La mia comprensione di versioni dei file di AccuRev è un po 'confuso. Credo che l'attributo versione sarà assegnato dal lavoro o flusso da cui è stato promosso il cambiamento più recente (non mantenute). E 'possibile che ci siano alcune relazioni flusso eredità che causa un file di avere gli attributi che non sembrano corretti fino a quando non tracciare fuori.

• Perché diff contiene quasi mai quello che loro mi aspetto di? Credo che ciò che di accadere è che diff contro di base mi mostra il diff contro corrente (in movimento) flusso di genitore, ma quello che voglio è solo quello di vedere i cambiamenti che ho fatto da quando ho aggiornato l'ultima volta.

Poi fare un diff contro "Backed", non contro Basis.

La configurazione semplice che funziona per me è: ho sempre creare la mia personale, flusso privata al largo di qualche flusso di sviluppo pubblico. Poi, quando faccio i cambiamenti che voglio checkin (o essere in grado di tornare a), promuovo al mio flusso. Io continuo a lavorare nel mio lavoro, e se voglio diff mio luogo di lavoro contro quello che ho fatto in precedenza o quello che sta succedendo sopra di me (i cambiamenti che altre persone hanno fatto), faccio un diff contro Backed.

Spiacente, questo è così lungo. Speriamo che aiuta ...

Answer 2

Dal momento che molti altri hanno tentato di rispondere alla tua domanda diretta - con la risposta di Dave è il più conciso e preciso - mi prendo una pugnalata a portata di proiettili:

•   

  Che cosa accade quando "Continuo" alcuni file e poi "promuovere la" loro?

  Un Mantenere di un file creerà una nuova versione di quel file, ancora privato al vostro spazio di lavoro. Eccellente per la codifica autonoma, la creazione di punti di deviazione, proprio sviluppo privato pianura. È possibile in qualsiasi momento in futuro tornare a qualsiasi versione precedente di un file conservato, sia da voi stessi o da qualsiasi altro collaboratore. Quando hai dimestichezza con la versione che si hanno in corso (avete compilato, costruito, testato, qualunque cosa), è possibile promuovere nel vostro flusso di genitore, esponendo così gli altri per la versione senza il rischio di rompere le cose come si può quando si commettono al momento del check-in.

•   

  Che cosa succede se io non promuovo gli stessi file come ho appena tenuto?

  autonomia di lavoro nuovo, totale. È possibile lavorare su 100 file in una sola volta, se siete il tipo di sviluppatore che può tenere traccia di quello che stai facendo. È possibile promuovere nessuno, tutti, uno, un po '- non importa -. E si può fare questo sulla timeline

•   

  Perché la storia a volte si mis-attribuita quando in conflitto non (anche noto come sovrapposizione) gli aggiornamenti avvengono? Questo, in particolare, ricorda una modalità di guasto di Subversion che, dalle spiegazioni di base che ho sentito, non credo dovrebbe esistere con AccuRev.

  Non sono sicuro so specificamente che cosa ti riferisci qui. Quando si esegue un aggiornamento in uno spazio di lavoro AccuRev, non sarà mai sovrascrivere il work-in-progress. Se stai lavorando su elementi che altrimenti sarebbero ereditati - che significa il contenuto nella gerarchia genitore è cambiato - saranno elencati come (sovrapposizione) nell'area di lavoro. Anche in questo caso, è possibile scegliere quando eseguire l'unione, e ancora aggiornare altri cambiamenti dall'alto, e anche continuare a lavorare sul file in conflitto. La fusione avviene nello spazio di lavoro, al contrario di promuovere al tempo, dandovi la possibilità di compilare una volta, costruire, testare il risultato prima di consegnare altrove.

•   

  Perché diff contiene quasi mai quello che loro mi aspetto di? Credo che ciò che di accadere è che diff contro di base mi mostra il diff contro corrente (in movimento) padre corrente, ma quello che voglio è solo quello di vedere i cambiamenti che ho fatto da quando ho aggiornato l'ultima volta.

  Un Diff contro Basis vi mostrerà come la versione nell'area di lavoro confronta con la versione che lo scorso ereditato da una creazione di aggiornamento o di lavoro. Un Diff contro Backed vi mostrerà come la versione paragona a quello che è attualmente nel flusso genitore. Quindi, se qualcuno ha promosso cambiamenti a questo file mentre si è ancora in corso la vostra, Diff contro Basis confronterà solo contro l'originale mentre Diff contro Backed confronta con i nuovi contenuti nel genitore. Per inciso, nella Storia -> Sfoglia visualizza versioni è possibile diff qualsiasi due versioni di un file contro l'altro

.

Speriamo che questo fornisce un po 'di prospettiva sulle vostre domande specifiche.

Answer 3

  

I spiegherebbe git come "un grafo orientato di commit in cui un commit è un diff, un genitore (o genitori) hash, e un hash di sé".

Un git repository è, FWIW, una foresta di alberi di storia, di cui commit foglie sono (impegnarsi metadati plus) alberi di directory e file. Non ci sono diff , non in Git, almeno quando si tratta di concept. Se il motore di archiviazione succede a fare deltification, questa è un'altra storia.

Per quanto riguarda AccuRev, ho guardato loro 2 minuti video introduttivo (link a scopo di riferimento, non pubblicità), e sembra più o meno come il vostro albero di storia SCM tempo-organizzati media (filiali). Gli elementi con l'acquosa-WAVE icona sono responsabili di filiali, e il giallo della cartella simile cosa è una copia di lavoro. Quando il presentatore sposta le copie di lavoro, egli sembra fare un rebase di tutti i suoi subordinati di copie di lavoro (il male che! Basti pensare ai conflitti di unione!). L'icona con tre punti verdi (l'elenco emissione) sarebbe un elenco di commit allora che è ciliegia-raccolto quando si copia.

In una frase: niente che non si conosce già attraverso la precedente esperienza al cvs / svn / git - si muovono lungo direi

.

Answer 4

derivato da ClearCase e prende dopo ClearCase UCM flussi .
(Il modello AccuRev ha alcune somiglianze con UCM, e ben accolto da ex utenti ClearCase )

Uno Stream è un Configurazione , che è la lista delle etichette (per componenti di sola lettura) o file (per i componenti scrivibili) è necessario il lavoro (compilazione, e / o di prova, e / o di debug, ...).

Questo è il motivo AccuRev si presenta come un basato sul flusso Architecture for SCM .

Se ha un flusso privato per sviluppatore (il flusso di lavoro) da cui è possibile promuovere a flussi più comuni. Ogni aggiornamento di promozione della configurazione (che è di nuovo solo la lista di ciò che è necessario al lavoro) del flusso genitore.

Answer 5

Ti darò il tecnico (non-biz) frase singolo in base allo stile della vostra D:

AccuRev adotta un approccio orientato oggetto alla modellazione s / w configurazioni. E 'così semplice ed è impressionante! Soprattutto se si sta modellando un flusso di lavoro o, meglio ancora, la creazione di erogazione continua (un altro argomento). Ma ho visto così, così tante persone respingere questa potente approccio tecnologia e modello di dati, perché non possono guardare oltre 'rami' tradizionali ala CVS, SVN, p4, cc, ad infinitum. La migliore analogia sarebbe quella di confrontare una serie di AccuRev flussi di regole in una configurazione specifica in ClearCase ... (nota: è solo un'analogia), ma molto più potente come flussi sono entità di prima classe che mantengono la configurazione e la storia in base al tempo.

Il trucco per AccuRev comprensione è che, mentre un dato "stream" -represents- una configurazione completa (cioè si può controllarlo fuori), il contenuto effettivo del flusso che sono determinati in modo dinamico aggregando qualsiasi file locale / modifiche dir, qualsiasi modifiche dal genitore, su l'albero fino alla cima dove il resto dei file sono raccolte. Quindi, ogni volta che si vede un 'albero' di corsi d'acqua, che non sono rami ... piuttosto una serie di configurazioni di successione basato dove la corrente superiore è come il 'superclasse' e tutti i [grandi] bambini sono [sub] sottoclassi. I nuovi file / modifiche dir siano promossi l'albero come vanno dallo sviluppo, l'integrazione, QA, ecc.

HTH _ dave