Motivi per preferire CVS su SVN o Git

Question

Ho appena trovato un progetto open source che utilizza ancora CVS. Mi chiedevo se ci fossero ancora dei motivi per preferire il CVS su SVN o Git al giorno d'oggi. (Non considero troppo pigro per migrare come risposta! ;-))

Il CVS ha qualcosa che gli altri mancano? Supponiamo, supporto per $ OS o $ fancy_tool?

In "What are the advantages of using SVN over CVS?" ci sono risposte elaborate perché non utilizzare CVS. Ma voglio chiedere il contrario. CVS non può essere tutto negativo. O è?

Answer 1

Uso ancora CVS per alcune delle mie cose personali.

A differenza di Git, è possibile controllare facilmente solo un sottoinsieme del repository.

E CVS assegna numeri di versione sequenziali (1.1, 1.2, 1.3, ...) a ciascun file. In Git, i numeri di versione sono checksum esadecimali di 40 caratteri. In SVN, i numeri di revisione sono sequenziali su tutto il repository; un determinato numero si applica all'intero repository.

E CVS consente di espandere i numeri di versione in ogni file durante il controllo, facilitando l'identificazione della versione di un file senza riferimento al repository da cui proviene.

Quindi trovo conveniente CVS (e talvolta anche RCS) quando il repository è una raccolta di file in gran parte non correlati, e sono più interessato a tenere traccia delle modifiche sui singoli file, ma le revisioni del repository nel loro complesso non sono particolarmente significativo.

(che non sta andando essere il caso se il repository contiene i file di origine utilizzati per costruire un singolo programma o una libreria,. In tal caso, si desidera una storia coerente per il progetto nel suo insieme)

Infine, CVS memorizza la cronologia di ciascun file in un singolo file (con lo stesso formato utilizzato da RCS) con un formato relativamente semplice. Almeno una volta, ho dovuto ricostruire manualmente un file CVS salvato che era stato danneggiato. Non sono sicuro di come avrei potuto farlo con SVN o Git.

UPDATE: questa domanda ha generato un paio di downvotes inspiegabili. Posso solo indovinare le ragioni (e non mi preoccupo molto del downvote occasionale), ma forse alcuni lettori pensano che io stia sostenendo CVS come un sistema migliore di SVN o Git. Io non sono; Sto semplicemente sottolineando che CVS può avere alcuni vantaggi in alcune circostanze abbastanza ristrette.

Answer 2

L'unica cosa che ho trovato nel mio uso limitato di CVS è che CVS considera i rami e i tag come diversi e li tratta come ciò che sono e non come semplici cartelle che SVN fa. Ci sono comandi specifici per questi e sono trattati come cittadini di prima classe del sistema di controllo della versione. Come si crea una filiale in SVN? svn copy. Etichetta? stesso. Qual è la differenza? Niente di veramente, tranne il modo in cui li tratti. Mentre si può dire che il modello SVN conduce alla semplicità, causa vari strumenti per fraintenderli e non ottenere il contesto delle cartelle. Se vedi Git, è simile al CVS in questo modo.

Ma sicuramente, non vi è alcun motivo per utilizzare CVS ora a un giorno, a parte le ragioni legacy. Molti dicono che SVN è stato costruito per essere un CVS migliore e in quasi tutti gli aspetti SVN è migliore ed è ampiamente utilizzato.

Answer 3

Devi capire che Subversion è stato scritto per sostituire direttamente CVS e gli errori che gli sviluppatori hanno con CVS. Subversion è stato scritto, in modo che gli utenti di CVS possano facilmente passare da CVS a Subversion poiché utilizzano lo stesso flusso di lavoro e molti concetti simili.

Questo è un po 'come chiedere come MS-DOS sia superiore a Windows come sistema operativo. Potrei inventare alcuni motivi fasulli ("Beh ... ... ehm ... MS-DOS ha bisogno di meno memoria."). Ma, alla fine, Windows è stato scritto per occuparsi del corto di MS-DOS.

Alcuni motivi per cui CVS è meglio Subversion semplicemente non reggono una volta capito il ragionamento:

• In CVS, tag e rami sono stati due completamente diversi concept. In realtà, non c'era molta differenza tra un tag o un ramo. Nel file CVS ,v, i rami e i tag sono stati entrambi sottoposti a alias di revisioni particolari all'inizio del file. Infatti, hai utilizzato lo stesso comando: cvs tag per creare un ramo o un tag. È uno dei motivi per cui Subversion non ha fatto una distinzione tra i due concetti. Tuttavia, trattando allo stesso modo rami e tag, Subversion ti ha dato un modo per tracciare la cronologia di un ramo o di un tag. Chi l'ha creato e quando? Su quale revisione si basava? È stato cambiato? Subversion ti offre anche un modo semplice per vedere tutti i tag o rami nel tuo repository. In CVS, devi passare attraverso ogni singolo file.
• CVS è più flessibile di Subversion perché Subversion più o meno ti costringe a lavorare in intere directory. In CVS, puoi controllare qua e là, apportare le modifiche e quindi taggarle tutte in una volta. Certo, questo è davvero un modo di lavorare brutto, terribile, terribile, pericoloso. Quello che succede di solito è che ti viene detto di fare una build basata su un vecchio tag, ma poi inserisci una mezza dozzina di modifiche ai file. Quindi, crea un nuovo tag. Il divertimento e l'eccitazione si verificano quando si tenta di seguire queste indicazioni. Hai fatto il nuovo tag sulla revisione 1.3.4.2.3.2.5.2 o 1.3.2.4.3.2.5.2?
• CVS consente di avere tag sparse e ramificazioni. Puoi avere un tag base, quindi aggiungere altri tag. Naturalmente, la ragione per la maggior parte dei siti è che potrebbe richiedere ore per ramificare o taggare un repository CVS veramente grande. Subversion fa la stessa cosa in un microsecondo.
• CVS utilizza il formato di file RCS standard, quindi è possibile risolvere i problemi nel repository. Tuttavia, la maggior parte delle volte, si finisce per creare più problemi di quelli che stai correggendo.

CVS è stato un grande miglioramento rispetto a RCS. In CVS, non era necessario bloccare un file prima di cambiarlo. In CVS, è possibile eseguire il checkout di interi sottotitoli senza scrivere una sorta di front end di sistema. RCS è stato sviluppato per la versione di singoli file. CVS ha revisionato l'intero repository come un singolo progetto.

RCS era di per sé un miglioramento per SCCS. Il formato del repository RCS era più facile da capire. L'espansione delle parole chiave ha funzionato meglio ed è stata meno criptica. Potresti avere rami di rami mentre SCCS ti lasciava con un solo livello di diramazione. RCS aveva il concetto integrato di tag mentre SCCS richiedeva di tenere traccia dei tag da soli.

E SCCS era molto meglio che non utilizzare un repository di origine.

La verità è che CVS è stato sostituito da Subversion, dal momento che Subversion è uscito più di dieci anni fa, tutti i lavori su CVS si sono fermati. Non penso nemmeno che i bug vengano corretti su CVS.

Answer 4

CVS, git e subversion hanno diversi design del flusso di lavoro. È inesatto e fuorviante dire (git/subversion è stato progettato per risolvere problemi con cvs). Piuttosto, è stata scritta sovversione, perché qualcuno voleva un flusso di lavoro diverso rispetto a CVS/RCS che funziona meglio. E poi git è stato scritto perché qualcuno voleva un altro flusso di lavoro diverso.

superficialmente, sovversione e CVS sono in qualche modo simili. Passando dalla memoria, CVS è adatto a coloro che amano usare RCS nel proprio repository di codice locale. RCS è bello in quanto richiede il controllo obbligatorio di un file. Ti rende esplicitamente a conoscenza dei file che stai toccando in qualsiasi momento. Evita così di "accidentalmente" toccare la parte del codice di qualcun altro.