it-swarm.it

Quali sono i tuoi sistemi di controllo versione preferiti?

Questa è più una domanda di discussione che un tentativo effettivo di determinare il "migliore", poiché ciò varia chiaramente in base alle esigenze dell'organizzazione. Sono più curioso degli argomenti a favore di diversi sistemi tra le categorie (centralizzato vs distribuito, aperto vs proprietario, ecc.).

Quindi, quale pensi sia il miglior sistema di controllo della versione?

41
Fishtoaster

Mutevole

Grazie alla sua sofisticata capacità di ramificare e unire il codice, è la migliore che abbia mai usato. L'intero paradigma DVCS ha molto senso. Non ho usato Git, ma suppongo che si qualifichi anche.

81
epotter

Git

Git è fantastico, e lo consiglierei in particolare a tutti coloro che lavorano su progetti open source: è molto più semplice contribuire con una piccola modifica una tantum a un progetto su Git, specialmente se è ospitato su GitHub, di quanto si occupi di e- inviando patch con SVN.

Un grande avvertimento per gli utenti Windows: gli strumenti Windows di Git, sebbene sicuramente utilizzabili, non sono del tutto all'altezza. Quando sono stato costretto a usare Windows per un po ', ho provato l'interfaccia Windows di Mercurial con uno strumento di integrazione Hg-Git in modo da poter usare i miei repository Git e ho scoperto che era molto più facile da usare.

72
Gaurav

Attenzione: da questo post ho trovato Mercurial e lo adoro molto meglio di SVN. Quindi questo post è un po 'obsoleto con i commenti Pro SVN e anti-DVCS generale, ma le cose anti-git sono ancora rilevanti


Sono un fan di SVN su Git.

Perché? Perché SVN è stato molto più semplice per un singolo sviluppatore o un piccolo team e git (in particolare msysgit) mi ha lasciato un cattivo gusto in bocca.

Quando stavo internando in un piccolo negozio, mi è stato presentato Git su Windows. Ho subito notato la quantità di lavoro necessaria per farlo funzionare con Github. Innanzitutto, ho dovuto generare una chiave privata ssh, incollare la chiave pubblica in Github, quindi richiamare lo spettacolo e aprire la mia chiave privata ogni volta che volevo Push, il che è stato estremamente fastidioso.

E non mi è mai piaciuto davvero che stavo tirando giù l'intero repository. Devo ammettere che non ho mai lavorato con nulla di enorme, ma avrei paura di scaricare il repository di KDE in Git se l'intero repository e le sue revisioni sono sul mio HD.

Poi c'è stato il processo confuso per effettuare un commit. TMK, ho dovuto prima "mettere in scena" tutti i file che volevo eseguire il commit (il che faceva schifo quando avevi molti file, mi ci è voluto un po 'per trovare il comando manuale per mettere in scena tutto), quindi eseguire il commit, quindi premere il pulsante principale repo (perché è un'operazione separata ?!).

Hai anche avuto i dati di commit non (!) Molto utili. Oh guarda, questo è commit 14f74433245ae17aeeaa parte dell'albero 2167a4934d0a4a7db0de e padre d7042abb4821d3faf600. Che diavolo significa? Dovrei essere in grado di capire le cose abbastanza rapidamente e non dovrei consultare una strana documentazione.

A proposito di documentazione, almeno quando la stavo usando, sembrava che tutto fosse in formato file man linux, IE confuso e inutile per me. Raramente riuscivo a trovare molto aiuto nei documenti e semplicemente ricorrevo a google.

E con commit, l'unica cosa che non mi è piaciuta è stata la mancanza di numeri di versione. Ora so che questo è dovuto al design di git, ma qualsiasi software ha bisogno di un numero di versione. Ricordo ancora il commit dei marker che si apriva dicendo "Versione modificata a 1.8.6" o qualcosa di simile, ma non si riusciva ancora a costruire numeri. Per me avere la versione 1.8.6.5164 (l'ultima parte è il numero di revisione) mi dice molto di più della semplice 1.8.6 e una nota che dice che qualcosa di secondario è cambiato, provalo

Essendo specifico per il software, il programma di base su Windows è msysgit, che è un'interfaccia terribile. Mi ha bloccato alcune volte, aveva un'interfaccia orribile e l'integrazione CLI-GUI era al massimo incerta. I drogati della riga di comando intorno a me odiavano ancora di più la gui.


Ora diamo un'occhiata a SVN. E dal momento che sono su Windows e ho un account Google, in particolare TortoiseSVN e Google Code.

Innanzitutto, completa l'integrazione Shell per fare tutto sul repository (e per te gente Linux, RabbitVCS fa la stessa cosa), non è necessaria alcuna GUI principale. Ottenere un repository è facile come un checkout, non è necessario SSH (non ricordo se Github ha richiesto SSH per i pull) e nessun repository completo + tutto il passato si impegna sul tuo HD.

Impegnarsi è estremamente facile, principalmente perché non sono richiesti SSH o stadiazione. Devi semplicemente controllare tutti i file che desideri utilizzando l'utilissima opzione seleziona tutto che nella mia versione di msysgit non era disponibile, digita un messaggio di commit e premi commit. Google Code ti chiede quindi le tue informazioni di accesso (che la maggior parte dei clienti memorizza) e il tuo lavoro. Semplice, facile e senza SSH

Numeri di versione? Con un po 'di codice semplice, puoi aggiungere un numero di versione e un numero di commit a tutti i checkout, il che rende le cose molto più facili. Ottieni anche numeri di versione utilizzabili che mostrano effettivamente una modifica, ad esempio 1.8.6.5165 è più recente di 1.8.6.5164.

Documentazione? Beh, è ​​difficile da dire. La tartaruga è documentata, ma non ho fatto riferimento alla documentazione ufficiale da così tanto tempo che non posso giudicare. Leggere una semplice guida introduttiva è stato abbastanza per me.

La fusione è qualcos'altro che non posso confrontare. Ho dovuto farlo una volta in Git quando qualcun altro ha commesso una modifica a un file su cui stavo lavorando, ma mai in SVN.


Quale consiglierei? Bene in grandi gruppi, git ha i suoi vantaggi, principalmente nel suo ciclo di sviluppo non lineare. In un altro progetto ho visto 4 programmatori iniziare in rami separati, quindi unire tutto il codice in modi molto strani che in qualche modo si sono trasformati nel ramo master finale. Github e msysgit avevano uno strumento di visualizzazione davvero piacevole per l'intero progetto che mi piaceva molto.

Per i progetti a singolo sviluppatore o per piccoli team, SVN sarebbe la migliore in quanto la maggior parte delle funzionalità di Gits non vengono utilizzate e si ottengono solo parti negative. La semplicità è una cosa così bella

24
TheLQ

La seguente citazione da Q4TD praticamente lo riassume per me:

“Ho amato Git fino a quando non l'ho provato. Ora adoro Mercurial. "

- Tor Norbye, Il Java Posse Podcast

Inoltre, hgsubversion rende un client Subversion abbastanza buono per Linux (dove di solito uso la riga di comando, a differenza di Windows dove di solito uso TortoiseSVN). Il più grande vantaggio: no .svn sottocartella in ogni cartella, solo un .hg al livello superiore.

Aggiornamento: In risposta alla richiesta di Alex nei commenti di "dire di più sul perché git non ha funzionato per te e su come Mercurial ha funzionato meglio":

Non direi che Git non funziona per me, ma Murcurial funziona meglio IMO.

In breve, questo è Mercurial:

alt text

e questo è Git:

alt text

E asserisco che Mercurial farà tutto ciò che la maggior parte degli sviluppatori ne avrà bisogno, senza dover consultare il manuale per capire come fare le cose di tutti i giorni.

Devo ammettere che ho usato Git solo occasionalmente, ma la comunità di programmatori ha gagato su linguaggi come Ruby e Python, in parte, per la loro concisione ed eleganza, mentre Git si sente come un cammello che è stato progettato da un comitato di cammelli.

Bah, ora guarda cosa hai fatto? C'è rant dappertutto. Muoviti, niente da vedere ... niente da vedere ...

Aggiornamento 2: E un altro apropos Tweet Mi sono appena imbattuto:

"Git diventa più facile una volta che hai avuto l'idea di base che i rami sono endofunctor omeomorfi che mappano le sotto-cartelle di uno spazio di Hilbert."

22
Evan

Non ho un singolo sistema di controllo della versione "migliore", ma piuttosto un singolo paradigma VCS migliore.

Ho usato diversi sistemi di controllo versione centralizzata e diversi sistemi di controllo versione distribuita. E posso dire senza esitazione che nessuno dovrebbe mai infliggere un CVCS a se stesso.

Non mi interessa quale DVCS che scegli (il mio preferito in particolare è Git), ma per favore fai un favore e usa un DVCS. Per uno: sarai molto più flessibile. I DVCS possono emulare banalmente un flusso di lavoro CVCS (semplicemente mai fork del repository e trattare i repository locali solo come un chache anziché un fork indipendente), mentre il contrario è impossibile. E mentre logicamente, facendo questa emulazione dovrebbe porta un po 'di sovraccarico (e in effetti lo fa), io ancora lo trovo più facile da usare (per non parlare di molto più performante a causa del locale memorizzazione nella cache) rispetto a qualsiasi CVCS che ho usato.

14
Jörg W Mittag

Non posso dire di aver incontrato il miglior software di controllo della versione, ma posso dirti di stare lontano da VSS e MKS. Entrambi sono cani che dovrebbero essere evitati a tutti i costi.

11
Walter

Non direi il meglio, ma uno con caratteristiche e concetti molto interessanti.

Fossil è un controllo di versione distribuito, tracciamento dei bug e progetto wiki costruito sul database SQLite come repository.

7
Maniero

Team Foundation Server

Perché:

  1. È un buono, solido VCS. (Non lo considero il migliore in ogni caso, ma ha degli extra di Nizza.)
  2. Il suo tracciamento di attività e bug integrato che si integra in Visual Studio mi aiuta a rimanere concentrato e a sapere di cosa ho bisogno per lavorare su tutto in un unico posto (applicare automaticamente un check-in a un bug o attività e chiuderlo è piuttosto buono, anche se puoi ottenere plugin per altri sistemi/Eclipse/ecc per farlo.)
  3. Integra attività/rilevamento bug/progetti direttamente in Project Server, quindi raramente devo tenere aggiornati i piani di progetto o le schede attività. Gli aggiornamenti al progetto in Project Server vengono automaticamente filtrati come attività in TFS e in Visual Studio affinché io possa vederli automaticamente.
5
Ryan Hayes

Ho usato una moltitudine di sistemi di controllo della versione nella mia lunga storia:

  • RPPT Rotoli di nastro di carta perforata). In una scatola da scarpe. Non sto scherzando.
  • PVCS - (sistema di controllo versione Polytron). Il primo vero VCS che ho usato.
  • SCCS - tanto tempo fa, non ricordo nulla di eccezionalmente buono o cattivo al riguardo.
  • RCS - come altri hanno sottolineato, preferirebbe succhiare palle di asino sudate.
  • CVS - è stato solo un dolore se usato con più di 2 programmatori. migliore caratteristica: rcs2cvs.
  • VSS: funziona, tranne il martedì, quando corrompe l'intero repository.
  • Perforce: costa più della mia auto. Il VCS stesso è accettabile, ma i ragazzi informatici che controllano ogni aspetto dell'uso non lo inseriranno mai nella mia lista "preferita".
  • SVN: ramificare e fondere è una cagna, ma in generale è migliore di qualsiasi altra. Non così buono con un sacco di piccoli cambiamenti eccezionali in attesa di revisione.
  • Mercurial - che poca esperienza che faccio con esso, mi piace. Potrei provarlo sul mio prossimo progetto.
  • Git - non ha mai avuto l'opportunità di usarlo.

Sebbene una coppia fosse orrore, la maggior parte andava "bene". Non mi hanno ostacolato. Finché uno strumento --- (non rende la mia vita significativamente più difficile, non mi dispiace davvero.

La cosa vera è capire i punti di forza e di debolezza di ciascuno. Comprendere l'ambiente di destinazione:

  • distribuito o locale
  • squadra piccola o grande
  • servizio vcs ospitato o meno
  • facile integrazione in altri strumenti

Joel ha anche rilasciato un'osservazione importante: impara lo strumento e il suo vero modello di utilizzo. Ha lottato potentemente cercando di far comportare Mercurial come Subversion.

4
brettmjohnson

Un nuovo sistema che utilizziamo nel mio ufficio è Plastic SCM (http://www.plasticscm.com/). Funziona molto bene per il nostro piccolo team e ci dà un grande controllo su ogni aspetto della gestione delle fonti.

2
Tom A

[~ ~ #] sccs [~ ~ #].

Oppure, se ti capita di non aver vissuto una grotta negli ultimi 38 anni, CSSC .

Seriamente, la mia azienda sta usando TeamWare , che è una specie di pseudo DVCS basato su SCCS.

No, non sto scherzando.

Sun è passato a Mercurial da TeamWare solo pochi anni fa. Ora dovresti capire perché Java sembra muoversi così lentamente.

1
Geoffrey Zheng

MPW: Beh, non posso davvero fare una recensione nonostante i miei sforzi.

Questo accadeva quando stavo imparando la programmazione al liceo e l'unico compilatore C++ veramente gratuito da avere era Macintosh Programming Workbench, che tenevo su un disco Zip e inserivo in qualunque Performa fosse disponibile in laboratorio.

MPW è arrivato con dozzine di strumenti (nessuno dei quali è stato resedit, ovvero un download separato), e uno di questi era un'utilità di controllo della versione. Ha aperto una piccola finestra con una singola riga di testo e dovevi trascinare i tuoi progetti o file su di essa. Non aveva documentazione che io fossi mai stato in grado di scoprire, insolito considerando che tutto il resto sembrava avere ottimi documenti, e quindi non ho mai abbastanza capito come usarlo.

Quello è stato il mio primo pennello con VC e l'ultimo per un bel po 'di tempo. Ora uso git per tutto.

RCS - Revision Control System

La codifica in solo è diventata così semplice.

0
Jé Queue

Ho usato Visual SourceSafe e lo odiavo, ma era meglio di niente, ma non di molto. Negli ultimi due anni, ho usato qualcosa chiamato QCVS da Qumasoft.com scritto, di proprietà e supportato dal programmatore Jim Voris. GUI semplice, prezzo economico, buon supporto.

Fa solo il lavoro.

0
crosenblum

Non ClearCase, almeno per un sistema Unix/Linux (forse con Windows il programma di installazione è più semplice). Per me è stato più semplice imparare un nuovo strumento, Perforce, piuttosto che aggiornare il nostro server ClearCase.

Attualmente uso Perforce al lavoro e mi piace, ma non ho idea se sia il migliore. Configurare l'ambiente della riga di comando e Perforce Server è un po 'complicato, ma l'utilizzo di Visual Client è abbastanza semplice. Mi piace pensare che gli utenti si divertano abbastanza con esso per le attività quotidiane; è solo l'installazione iniziale richiede un po 'di lavoro.

0
Chance