Differenza tra GIT e CVS

Qual è la differenza tra i sistemi di controllo versione Git e CVS?

Uso felicemente CVS da oltre 10 anni e ora mi è stato detto che Git è molto meglio. Qualcuno potrebbe spiegare qual è la differenza tra i due e perché uno è migliore dell'altro?

La differenza principale è che (come già detto in altre risposte) CVS è (vecchio) sistema di controllo centralizzato della versione, mentre Git è distribuito.

Ma anche se usi il controllo versione per singolo sviluppatore, su un singolo computer (account singolo), ci sono alcune differenze tra Git e CVS:

• Impostazione del repository . Git archivia il repository nella .gitdirectory nella directory principale del progetto; CVS richiede l'impostazione di CVSROOT, un posto centrale per la memorizzazione delle informazioni di controllo versione per diversi progetti (moduli). La conseguenza di tale progetto per l'utente è che l'importazione di fonti esistenti nel controllo della versione è semplice come "git init && git add. && git commit" in Git, mentre è più complicato in CVS.

• Operazioni atomiche . Poiché CVS all'inizio era un insieme di script attorno al sistema di controllo della versione RCS per file, i commit (e altre operazioni) non sono atomici in CVS; se un'operazione nel repository viene interrotta nel mezzo, il repository può essere lasciato in uno stato incoerente. In Git tutte le operazioni sono atomiche: o hanno successo nel loro insieme o falliscono senza alcuna modifica.

• Cambi . Le modifiche al CVS sono per file, mentre le modifiche (commit) in Git si riferiscono sempre all'intero progetto. Questo è un cambio di paradigma molto importante . Una delle conseguenze di ciò è che è molto facile in Git ripristinare (creare un cambiamento che annulla) o annullare intero cambiamento; altra conseguenza è che in CVS è facile fare checkout parziali, mentre attualmente è quasi impossibile in Git. Il fatto che le modifiche siano per file, raggruppate insieme ha portato all'invenzione del formato del registro delle modifiche GNU per i messaggi di commit in CVS; Gli utenti Git usano (e alcuni strumenti Git si aspettano) una convenzione diversa, con una riga che descrive il cambiamento (riepilogativo), seguito da una riga vuota, seguita da una descrizione più dettagliata delle modifiche.

• Revisioni dei nomi / numeri di versione . C'è un altro problema connesso al fatto che in CVS le modifiche sono per file: numeri di versione (come puoi vedere a volte in ; lo stesso vale in Git se vuoi usare un nome come 'v1.5.6-rc2' per alcune versioni di un progetto ... ma i tag in Git sono molto più facili da usare. nell'espansione delle parole chiave , vedi sotto) come 1.4 riflettono quante volte il file dato è stato cambiato. In Git ogni versione di un progetto nel suo insieme (ogni commit) ha il suo nome univoco dato dall'id SHA-1; di solito sono sufficienti i primi 7-8 caratteri per identificare un commit (non è possibile utilizzare un semplice schema di numerazione per le versioni nel sistema di controllo della versione distribuita - che richiede l'autorità di numerazione centrale). In CVS per avere il numero di versione o il nome simbolico che si riferisce allo stato del progetto nel suo insieme si usano i tag

• Ramificazione facile . Le filiali nel CVS sono a mio avviso eccessivamente complicate e difficili da gestire. Devi taggare i rami per avere un nome per un intero ramo del repository (e anche questo può fallire in alcuni casi, se ricordo bene, a causa della gestione per file). Aggiungete a ciò il fatto che CVS non ha il monitoraggio delle unioni , quindi è necessario ricordare o contrassegnare manualmente i punti di fusione e di ramificazione e fornire manualmente le informazioni corrette per "cvs update -j" per unire i rami, e lo rende per la ramificazione essere inutili difficili da usare. In Git creare e unire filiali è molto semplice; Git ricorda tutte le informazioni richieste da solo (quindi unire un ramo è facile come "git merge branchname ") ... doveva farlo, perché lo sviluppo distribuito porta naturalmente a più rami.

  Ciò significa che si è in grado di utilizzare rami di argomenti , ovvero sviluppare una funzione separata in più passaggi in un ramo di funzioni separato.

• Rinomina (e copia) il monitoraggio . Le rinominazioni dei file non sono supportate in CVS e la ridenominazione manuale potrebbe interrompere la cronologia in due o portare a cronologia non valida in cui non è possibile ripristinare correttamente lo stato di un progetto prima di rinominare. Git utilizza il rilevamento euristico della ridenominazione, basato sulla somiglianza dei contenuti e del nome del file (questa soluzione funziona bene nella pratica). È inoltre possibile richiedere il rilevamento della copia dei file. Ciò significa che:

  • esaminando il commit specificato otterrai informazioni sulla rinominazione di alcuni file,
  • l'unione corretta prende in considerazione i nomi (ad esempio se il file è stato rinominato in un solo ramo)
  • "git blame", l'equivalente (migliore) di "cvs annotate", uno strumento per mostrare la cronologia del contenuto di un file, può seguire lo spostamento del codice anche attraverso i nomi

• File binari . CVS ha solo un supporto molto limitato per i file binari (ad esempio immagini), che richiede agli utenti di contrassegnare esplicitamente i file binari quando aggiungono (o in seguito usando "cvs admin", o tramite wrapper per farlo automaticamente in base al nome del file), per evitare che il mangling di file binario tramite conversione di fine riga ed espansione delle parole chiave. Git rileva automaticamente i file binari in base ai contenuti allo stesso modo in cui CNU diff e altri strumenti lo fanno; puoi ignorare questo rilevamento usando il meccanismo gitattributes. Inoltre, i file binari sono sicuri contro la manipolazione irrecuperabile grazie all'impostazione predefinita di 'safecrlf' (e al fatto che è necessario richiedere la conversione di fine riga, sebbene ciò possa essere attivato per impostazione predefinita a seconda della distribuzione) e che (limitata) parola chiave l'espansione è un 'opt-in' rigoroso in Git.

• Espansione delle parole chiave . Git offre un set di parole chiave molto, molto limitato rispetto al CVS (per impostazione predefinita). Ciò è dovuto a due fatti: i cambiamenti in Git sono per repository e non per file, e Git evita di modificare i file che non sono cambiati quando si passa a un altro ramo o si riavvolge in un altro punto della storia. Se vuoi incorporare il numero di revisione usando Git, dovresti farlo usando il tuo sistema di compilazione, ad esempio il seguente esempio di script GIT-VERSION-GEN nei sorgenti del kernel Linux e nelle fonti Git.

• La modifica si impegna . Poiché in VCS distribuito come Git act of publishing è separato dalla creazione di un commit, si può cambiare (modificare, riscrivere) parte della cronologia non pubblicata senza disturbare altri utenti. In particolare se noti errori di battitura (o altri errori) nel messaggio di commit o un bug in commit, puoi semplicemente usare "git commit --amend". Questo non è possibile (almeno non senza un pesante hacker) in CVS.

• Più strumenti . Git offre molti più strumenti rispetto a CVS. Uno dei più importanti è " git bisect " che può essere usato per trovare un commit (revisione) che ha introdotto un bug; se i tuoi commit sono piccoli e indipendenti, dovrebbe essere abbastanza facile scoprire dove si trova il bug.

Se stai collaborando con almeno un altro sviluppatore, troverai anche le seguenti differenze tra Git e CVS:

• Commit prima della fusione Git usa commit-before-merge piuttosto che, come CVS, merge-before-commit (o update-then-commit ). Se mentre stavi modificando i file, preparandoti a creare un nuovo commit (nuova revisione) qualcuno ha creato un nuovo commit sullo stesso ramo ed è ora nel repository, CVS ti costringe ad aggiornare la tua directory di lavoro e risolvere i conflitti prima di permetterti di eseguire il commit. Questo non è il caso di Git. Prima esegui il commit, salvando il tuo stato nel controllo versione, quindi unisci le altre modifiche dello sviluppatore. Puoi anche chiedere all'altro sviluppatore di eseguire l'unione e risolvere i conflitti.

  Se si preferisce avere una cronologia lineare ed evitare le fusioni, è sempre possibile utilizzare il flusso di lavoro commit-merge-recommit tramite "git rebase" (e "git pull --rebase"), che è simile al CVS in quanto si riproducono le modifiche in alto di stato aggiornato. Ma ti impegni sempre per primo.

• Non è necessario un repository centrale Con Git non è necessario disporre di un'unica posizione centrale in cui eseguire le modifiche. Ogni sviluppatore può avere il proprio repository (o repository migliori: uno privato in cui svolge lo sviluppo e uno pubblico in cui pubblica quella parte che è pronta), e possono estrarre / recuperare da ogni altro repository, in moda simmetrica. D'altra parte è comune che un progetto più ampio abbia un repository centrale socialmente definito / nominato da cui tutti attingono (ottengono le modifiche).

Infine, Git offre molte più possibilità quando è necessaria la collaborazione con un gran numero di sviluppatori. Di seguito ci sono differenze tra CVS in Git per le diverse fasi di interesse e posizione in un progetto (sotto controllo di versione usando CVS o Git):

• in agguato . Se sei interessato solo a ricevere le ultime modifiche da un progetto, ( nessuna propagazione delle tue modifiche ), o fare sviluppo privato (senza contribuire ai progetti originali); oppure usi progetti stranieri come base del tuo progetto (le modifiche sono locali e non ha senso pubblicarle).

  Git supporta qui l'accesso anonimo di sola lettura non autenticato tramite git://protocollo efficiente personalizzato o se si è dietro il blocco firewall DEFAULT_GIT_PORT(9418) è possibile utilizzare il semplice HTTP.

  Per CVS la soluzione più comune (a quanto ho capito) per l'accesso in sola lettura è l' account guest per il protocollo 'pserver' su CVS_AUTH_PORT(2401), di solito chiamato "anonimo" e con password vuota. Le credenziali sono archiviate per impostazione predefinita nel $HOME/.cvspassfile, quindi è necessario fornirle una sola volta; tuttavia, questo è un po 'di barriera (devi conoscere il nome dell'account ospite o prestare attenzione ai messaggi del server CVS) e fastidio.

• sviluppatore marginale (collaboratore foglia) . Un modo per propagare le modifiche in OSS è l' invio di patch via e-mail . Questa è la soluzione più comune se sei (più o meno) sviluppatore accidentale, invio di singole modifiche o singole correzioni. BTW. l'invio di patch può avvenire tramite la scheda di revisione (sistema di revisione delle patch) o mezzi simili, non solo via e-mail.

  Git offre qui strumenti che aiutano questo meccanismo di propagazione (pubblicazione) sia per il mittente (client) sia per il manutentore (server). Per le persone che vogliono inviare le loro modifiche via e-mail c'è lo strumento " git rebase " (o "git pull --rebase") per riprodurre le tue modifiche sulla versione corrente a monte, quindi le tue modifiche sono in cima alla versione corrente (sono nuove ) e " git format-patch " per creare e-mail con il messaggio di commit (e la paternità), cambiano sotto forma di formato diff unificato (esteso) (più diffstat per una revisione più semplice). Il gestore può trasformare direttamente tale e-mail in commit preservando tutte le informazioni (incluso il messaggio di commit) usando " git am ".

  CVS non offre tali strumenti: è possibile utilizzare "cvs diff" / "cvs rdiff" per generare modifiche e utilizzare la patch GNU per applicare le modifiche, ma per quanto ne so non c'è modo di automatizzare l'applicazione del messaggio di commit. CVS doveva essere utilizzato nella modalità client <-> server ...

• tenente . Se sei un manutentore di una parte separata di un progetto (sottosistema) o se lo sviluppo del tuo progetto segue il flusso di lavoro "network of trust" utilizzato nello sviluppo del kernel Linux ... o solo se hai il tuo repository pubblico e le modifiche che vuoi pubblicare sono troppo grandi per essere inviati via e-mail come serie di patch , puoi inviare una richiesta pull al manutentore (principale) del progetto.

  Questa è una soluzione specifica per i sistemi di controllo della versione distribuita , quindi CVS non supporta questo tipo di collaborazione. Esiste anche uno strumento chiamato "git request-pull" che aiuta a preparare la posta elettronica da inviare al manutentore con la richiesta di estrarre dal proprio repository. Grazie a "git bundle" puoi utilizzare questo meccanismo anche senza avere un repository pubblico, inviando bundle di modifiche via e-mail o sneakernet. Alcuni dei siti di hosting Git come GitHub hanno il supporto per la notifica che qualcuno sta lavorando (ha pubblicato alcuni lavori) sul tuo progetto (a condizione che utilizzi lo stesso sito di hosting Git), e per il PM di una sorta di richiesta pull.

• sviluppatore principale , ovvero qualcuno che pubblica direttamente le proprie modifiche (nel repository principale / canonico). Questa categoria è più ampia per i sistemi di controllo della versione distribuita, poiché avere più sviluppatori con accesso in scrittura al repository centrale non è solo un flusso di lavoro possibile (è possibile avere un unico manutentore che spinge le modifiche al repository canonico, un insieme di tenenti / manutentori del sottosistema da cui lui / lei pull e un'ampia gamma di sviluppatori foglia che inviano patch via mail o alla mailing list del manutentore / progetto o a uno dei tenenti / manutentori).

  Con Git puoi scegliere di utilizzare il protocollo SSH ( protocollo git racchiuso in SSH) per pubblicare le modifiche, con strumenti come "git shell" (per aiutare la sicurezza, limitare l'accesso degli account di shell) o Gitosis (per gestire l'accesso senza richiedere account di shell separati ) e HTTPS con WebDAV, con normale autenticazione HTTP.

  Con CVS è possibile scegliere tra il protocollo pserver personalizzato non crittografato (testo normale) o l'utilizzo della shell remota (dove si dovrebbe davvero usare SSH ) per pubblicare le modifiche, che per il sistema di controllo centralizzato della versione significa confermare le modifiche (creare commit). Bene, puoi anche tunnelare il protocollo 'pserver' usando SSH, e ci sono strumenti di terze parti che automatizzano questo ... ma non penso che sia facile come ad esempio Gitosis.

In generale, i sistemi di controllo della versione distribuita, come Git, offrono una selezione molto più ampia di possibili flussi di lavoro. Con i sistemi di controllo centralizzato della versione, come CVS, per necessità devi distinguere tra persone con accesso commit al repository e quelle senza ... e CVS non offre alcuno strumento per aiutare ad accettare contributi (tramite patch) da persone senza commettere l'accesso.

Karl Fogel in produzione di software open source nella sezione sul controllo delle versioni afferma che è meglio non fornire controlli troppo rigidi, rigidi e rigorosi su aree in cui è consentito apportare modifiche al repository pubblico; è molto meglio fare affidamento (per questo) su restrizioni sociali (come la revisione del codice) piuttosto che su restrizioni tecniche; i sistemi di controllo della versione distribuita riducono ulteriormente l'IMHO ...

HTH (Spero che aiuti)

Git è un DVCS , invece che CVS è centralizzato. La descrizione semplicistica sarà: otterrai tutti i vantaggi del controllo versione quando non sei connesso a nessuno dei molteplici repository possibili, più le operazioni sono più veloci.

Il sito web Git spiega questo meglio probabilmente.

La funzione del mio animale domestico è in grado di eseguire commit in modalità offline. E la velocità, l'incredibile velocità alla quale accade tutto tranne che spingere e tirare. (E queste operazioni sono progettate in modo non distruttivo, quindi puoi spingere / tirare quando vai a prendere un caffè se il tuo repository centrale è in ritardo.) Un'altra cosa bella è che vengono incluse le batterie: l'integrato gitkè un visualizzatore di cronologia abbastanza buono; git guiè uno strumento di commit abbastanza buono; con colorazione uscita, git add -i, git add -p, git rebase -isono buone interfacce interattive sufficienti; git daemone git instawebsono sufficienti per la collaborazione ad hoc se non si desidera / non si può giocherellare con il proprio repository centrale.

Sono anche un utente per lo più felice di oltre 10 anni di cvs, anche se mi piace anche git, e con il tempo arriverà a preferirlo, anche se la maggior parte dei progetti su cui lavoro attualmente utilizza cvs o svn, e non possiamo sembrare per convincere la burocrazia in cui lavoro a lasciarci fare un buco nel firewall.

Un paio di cose che rendono il cv più bello di quanto potrebbe essere altrimenti sono cvsps, e un altro sono gli script di patch di Andrew Morton o la trapunta. Cvsps ti consente di ricostituire i file multipli di un commit in una singola patch (e quindi estrarre "changeset" da CVS) mentre la trapunta, o gli script di patch di Andrew Morton ti consentono di inserire "changeset" sensibili in cvs in modo abbastanza semplice e comodo, permettendoti di lavorare su più cose simultaneamente mantenendole separate prima di impegnarsi. CVS ha le sue stranezze, ma sono abituato alla maggior parte di loro.

"Usare felicemente CVS per oltre x anni", è un'idea interessante :-) È un enorme passo avanti nel mantenere molte copie, ma ...

Immagino che ti sia abituato a tutte le sue stranezze, o non fai molto ramificazione e fusione. C'è una possibilità peggiore;

Le persone della tua organizzazione si sono abituate alle limitazioni del CV e le tue pratiche di lavoro si sono adattate di conseguenza;

per esempio, non avere mai più di uno sviluppatore che lavora su un pacchetto alla volta, usando solo la diramazione in caso di emergenza ecc.

Il principio di base è che più è difficile qualcosa, meno persone lo fanno.