Non si utilizza il controllo di versione distribuito?

Question

Mi piacerebbe sentire da persone che stanno usando il controllo di versione distribuito (aka controllo di versione distribuito e decentralizzato di controllo di versione) e come si trovano.Che cosa si sta utilizzando, Mercurial, Darcs, Git, Bazar?Stai ancora usando?Se hai utilizzato client/server rcs in passato, si stanno trovando di meglio, peggio o semplicemente diversi?Cosa potete dirmi che mi avrebbe portato a saltare sul carro?O saltare per quella materia, sarei curioso di sentire da persone con esperienze negative come bene.

Attualmente sto cercando di sostituire il nostro attuale sistema di controllo di origine (Subversion), che è l'impulso per questa domanda.

Sarei interessato soprattutto a chiunque abbia usato con i colleghi in altri paesi, dove le macchine non possono essere allo stesso tempo, e la connessione è molto lenta.

Se non siete sicuri di ciò che di controllo di versione distribuito è, qui ci sono un paio di articoli:

Introduzione al Controllo di Versione Distribuito

Voce Di Wikipedia

Answer 1

Sto usando Mercurial, sia nel lavoro che nei miei progetti personali, e sono davvero felice.I vantaggi che vedo sono:

1. Versione locale di controllo. A volte sto lavorando a qualcosa, e voglio mantenere una cronologia delle versioni, ma io non sono pronto a spingere al repository centrali.Con la distribuzione di VCS, appena posso impegnare il mio locale repo fino a quando è pronto, senza diramazioni.In questo modo, se altre persone a fare le modifiche che ho bisogno, posso ancora farli e li integrano nel mio codice.Quando sono pronto, mi spinge fuori per il server.
2. Meno conflitti di fusione. Ancora succedere, ma sembrano essere meno frequenti, e sono meno di un rischio, perché tutto il codice viene controllato nel mio locale repo, quindi, anche se ho maligna, l'unione, posso sempre indietro e farlo di nuovo.
3. Separato repo come rami. Se ho un paio di sviluppo di vettori in esecuzione allo stesso tempo, posso solo fare diversi cloni di mio repo e sviluppare ogni funzione in modo indipendente.In questo modo, se qualcosa va rottamato o scivolato, non devo tirare i pezzi.Quando si è pronti ad andare, ho appena li fondono insieme.
4. Velocità. Mercurial è molto più veloce da lavorare, soprattutto perché la maggior parte dei comuni operazioni locali.

Naturalmente, come con qualsiasi nuovo sistema, c'era un po ' di dolore durante la transizione.Devi pensare di controllo di versione in modo diverso rispetto a quando si utilizza SVN, ma in generale penso che è molto vale la pena.

Answer 2

Nel luogo dove lavoro, abbiamo deciso di spostare da SVN Bazar (dopo la valutazione di git e mercurial).Bazaar è stato facile per iniziare, con comandi semplici (non come il 140 comandi git ha)

I vantaggi che noi vediamo è la possibilità di creare filiali locali e lavorare su di esso, senza disturbare la versione principale.Anche essere in grado di lavorare senza l'accesso alla rete, facendo diff è più veloce.

Un comando in bzr che mi piace è il ripiano in estensione.Se si inizia a lavorare su due logicamente diversi pezzi di codice in un unico file e si vuole impegnare un solo pezzo, è possibile utilizzare il ripiano estensione letteralmente accantonate le altre modifiche successive.In Git si può fare lo stesso con giocando con l'indice(area di sosta) ma bzr ha una migliore interfaccia utente.

La maggior parte delle persone sono riluttanti a muoversi su come si deve scrivere due comandi per commettere e push (bzr ci + bzr push).Inoltre, è stato difficile per loro capire il concetto di rami e di fusione (non si usa o di rami e li unisce in svn).

Una volta capito che, aumenterà il numero di sviluppatori di produttività.Fino a che tutti capiscono di che, ci saranno coerenti di comportamento da parte di tutti.

Answer 3

Al mio posto di lavoro, siamo passati a Git da CVS circa due mesi fa (la maggior parte della mia esperienza con Subversion).Mentre c'è stata una curva di apprendimento coinvolti nel familiarizzare con il sistema distribuito, ho trovato il Git di essere superiore in due aree chiave:la flessibilità dell'ambiente di lavoro e la fusione.

Non devo essere sul nostro VPN, o addirittura avere la connettività di rete, per avere accesso a tutte le funzionalità di controllo versioni.Questo significa che è possibile sperimentare con idee o eseguire la rifattorizzazione ovunque mi capita di essere, quando la voglia scioperi, senza dover ricordare il check-in quell'enorme commettere ho costruito o preoccuparsi di essere in grado di tornare quando ho fatto un pasticcio.

Perché fonde vengono eseguite sul lato client, sono molto più veloce e meno soggetto a errori di avvio di un server-side unione.

Answer 4

La mia azienda utilizza attualmente Subversion, CVS, Mercurial e git.

Quando abbiamo iniziato cinque anni fa abbiamo scelto di CVS, e usiamo ancora che nella mia divisione per il nostro sviluppo e il rilascio ramo di manutenzione.Tuttavia, molti dei nostri sviluppatori di utilizzare Mercurial singolarmente come un modo per avere privato i checkpoint senza il dolore di CVS rami (e in particolare l'unione) e stiamo iniziando a utilizzare Mercurial per alcuni rami che hanno fino a 5 persone.C'è una buona probabilità ci sarà finalmente fosso CVS in un altro anno.Il nostro uso dei Mercurial cresciuta in modo organico;alcune persone ancora mai nemmeno toccare, perché sono felice con CVS.Chiunque abbia provato Mercurial ha finito per essere felici, senza molto di una curva di apprendimento.

Ciò che funziona davvero bene per noi con Mercurial è che il nostro (fatte in casa) continuous integration server in grado di monitorare sviluppatore Mercurial repository così come la linea principale.Così, le persone a impegnarsi per la loro repository, ottenere il nostro server di integrazione continua a controllare, e quindi pubblicare le modifiche.Sosteniamo un sacco di piattaforme, quindi non è possibile fare un decente livello di controlli manuali.Un'altra vittoria è che si confonde spesso facile, e quando non è facile avere le informazioni di cui avete bisogno per fare un buon lavoro per la stampa unione.Una volta che qualcuno ottiene la versione fusa per lavoro, può spingere la loro unione di insiemi di modifiche e quindi nessuno deve ripetere lo sforzo.

L'ostacolo più grande è che avete bisogno di rewire che gli sviluppatori e i gestori di cervello in modo che si allontanano dal singolo lineare modello di filiale.La migliore medicina per questo è una dose di Linus Torvalds dicendo sei stupido e brutto se si utilizza centralizzata SCM.Una buona storia, strumenti di visualizzazione, sarebbe di aiuto, ma io non sono ancora soddisfatti con ciò che è disponibile.

Mercurial e CVS entrambi funzionano bene per noi, con gli sviluppatori che utilizzano un mix di Windows, Linux e Solaris, e ho notato nessun problema con i vari fusi orari.(In realtà, questo non è troppo difficile;basta usare epoca secondi internamente, e mi aspetto tutti i principali sistemi SCM ottenere questo diritto).

È stato possibile, con una discreta quantità di sforzo, di importare il nostro principale CVS storia, la storia di Mercurial.Sarebbe stato più facile se le persone non avessero deliberatamente introdotto angolo casi in nostro principale CVS storia come un modo per testare la storia di strumenti di migrazione.Ciò ha incluso la fusione di alcuni Mercurial rami in CVS storia, in modo che il progetto sembra sia stato in uso dal primo giorno.

Il nostro gruppo di progettazione del silicio ha scelto di Subversion.Essi sono principalmente otto fusi orari di distanza dal mio ufficio, e anche su una buona linea dedicata tra i nostri uffici SUbversion le estrazioni sono dolorose, ma lavorabile.Un grande vantaggio dei sistemi centralizzati è che è potenzialmente possibile controllare big binari in esso (ad es.fornitore rilascia) senza fare tutti i repository distribuiti enorme.

Si usa git per lavorare con il kernel Linux.Git sarebbe più adatto per noi, una volta che un nativo di Windows versione è maturo, ma penso che la Mercurial design è così semplice ed elegante che ti bastone con esso.

Answer 5

Non utilizzo di sorgente distribuita controllo di me stesso, ma forse queste domande e risposte su questioni di darvi alcuni spunti:

• Sorgente distribuita opzioni di controllo
• Perché git meglio di Subversion

Answer 6

Ho personnaly utilizzare Mercurial sistema di controllo di origine.L'ho usata per un po ' più di un anno da ora.In realtà fu la mia prima esperienza con un VSC.

Ho provato Git, ma mai spinto a farlo perché l'ho trovato era troppo per quello che mi serviva.Mercurial è davvero facile da prendere se sei un Sovvertimento dell'utente, in quanto condivide un sacco di comandi con esso.Plus trovo la gestione del mio repository per essere davvero facile.

Ho 2 modi per condividere il mio codice con la gente:

• Condivido un server con un co-lavoratore e di tenere una repo principale per il nostro progetto.
• Per qualche progetto OSS lavoro, siamo noi a creare la patch del nostro lavoro, con Mercurial (hg di esportazione) e il maintener del progetto basta applicarli sul repository (hg di importazione)

Davvero facile da lavorare, ma molto potente.Ma in generale, la scelta di un VSC in realtà dipende il nostro progetto ha bisogno...

Answer 7

Indietro prima che si spegne di Sole postazioni di lavoro per sistemi embedded sviluppo siamo stati con Sole TeamWare soluzione.TeamWare è una cucina completamente la soluzione di distribuzione utilizzando CSSC repository locale revisioni dei file di sistema e quindi wrapper che con una serie di strumenti per gestire le operazioni di fusione (fatto attraverso ramo di ridenominazione) al repository centralizzato di cui non ci possono essere molti.Infatti, poiché esso è distribuito, non c'è davvero alcun repository master di per se' (tranne che per convenzione se si desidera) e tutti gli utenti hanno la propria copia di tutta la struttura di origine e delle revisioni.Durante "rimesso" operazioni di merge tool con 3-way diff algoritmicamente ordina che cosa è cosa e consente di combinare le modifiche da diversi sviluppatori che si sono accumulate nel tempo.

Dopo il passaggio a Windows per la nostra piattaforma di sviluppo, abbiamo finito per passare a AccuRev.Mentre AccuRev, perché dipende da un server centralizzato, non è davvero una soluzione distribuita, logicamente da un modello di flusso di lavoro è molto vicino.Dove TeamWare avrebbe avuto completamente separate le copie di tutto ciò che a ogni cliente, comprese tutte le revisioni di tutti i file, sotto AccuRev questo è mantenuto nel database centrale e locale macchine client solo il file flat versione attuale delle cose per la modifica a livello locale.Tuttavia queste copie in locale può essere la versione tramite il client di connessione al server e tracciato completamente separatamente da tutte le altre modifiche (ie:rami) implicitamente creati da altri sviluppatori

Personalmente, penso che il modello distribuito implementato da TeamWare o una sorta di ibrido implementato il modello da AccuRev è superiore completamente le soluzioni centralizzate.La ragione principale di questo è che non vi è alcuna nozione di dover estrarre un file o di avere un file bloccato da un altro utente.Inoltre, gli utenti non devono creare o definire i rami;gli strumenti per fare questo per voi, in modo implicito.Quando ci sono grandi squadre o team diversi che contribuiscono a o il mantenimento di un insieme di file di origine di questo risolve strumento "generato" di chiusura relative collisioni e permette le modifiche al codice di essere coordinato di più gli sviluppatori, che in ultima analisi, devono coordinare le modifiche comunque.In un certo senso, il modello distribuito, consente una più sottile grana "blocco", piuttosto che il corso di specifiche blocco istituito dai modelli centralizzati.

Answer 8

Hanno usato darcs, in un grande progetto (GHC) e per un sacco di piccoli progetti.Ho un rapporto di amore e odio con darcs.

Vantaggi:incredibilmente facile da impostare repository.È molto facile da spostare cambiamenti tra i repository.Molto facile da clonare e provare a 'rami' nel repository separati.Molto facile da fare 'impegna' in piccolo coerente gruppi che rende il senso.Molto facile rinominare i file e gli identificatori.

Svantaggi:nessuna nozione di storia---non si puo ' recuperare 'lo stato delle cose, il 5 agosto'.Non ho mai davvero capito come usare darcs per tornare a una versione precedente.

Affare-breaker:darcs non scala.Io (e molti altri) hanno ottenuto in grossi guai con GHC utilizzando darcs.Ho avuto blocchi con il 100% di utilizzo della CPU per 9 giorni cercando di tirare in 3 mesi di cambiamenti.Ho avuto una brutta esperienza la scorsa estate in cui ho perso due settimane cercando di fare darcs funzione e, infine, ricorso per la riproduzione di tutti i miei cambiamenti, a mano, in un incontaminato repository.

Conclusione:darcs è grande se si desidera un semplice, modo leggero per mantenere se stessi dal tiro di te stesso in piedi per il vostro hobby progetti.Ma anche con alcuni problemi di prestazioni rivolte in darcs 2, non è ancora per la forza industriale di roba.Io non credo nel darcs fino a che il decantato "teoria della patch' è qualcosa di un po ' più di un paio di equazioni e qualche bella foto;Voglio vedere una vera e propria teoria, pubblicata in un referee sede.È passato del tempo.

Answer 9

Io amo molto il Git, soprattutto con GitHub.E ' così bello essere in grado di commit e rollback a livello locale.E cherry-picking unisce, mentre non è banale, non è terribilmente difficile, e molto più avanzato rispetto a qualsiasi Svn o CVS può fare.

Answer 10

Il mio gruppo di lavoro sta usando Git, ed è stato tutta la differenza del mondo.Siamo stati con CSSC e un mucchio fumante di csh script per gestire abbastanza grandi e complessi progetti di codice condiviso tra di loro (tentato, comunque).

Con Git, submodule fa in modo che un sacco di questa roba facile, e solo un minimo di creazione di script è necessario.Il nostro comunicato di ingegneria sforzo è andato via perché i rami sono facili da gestire e tenere traccia di.Essere in grado di a buon mercato branca e unione fa davvero ragionevolmente facile da mantenere un'unica raccolta di fonti di diversi progetti (contratti), mentre prima, con un'interruzione per il tipico flusso delle cose era molto, molto costoso.Abbiamo anche scoperto che il scriptabability di Git per essere un enorme inoltre, poiché siamo in grado di personalizzare il comportamento attraverso ganci o tramite script che fare . git-sh-setup, e non mi sembrano un mucchio di kludges come prima.

Anche noi a volte sono le situazioni in cui dobbiamo mantenere la nostra versione di controllo distribuiti, non in rete siti (in questo caso, scollegato secure labs), e Git ha meccanismi per affrontare quella con meno problemi (bundle, la base clone meccanismo, formattato patch, ecc).

Alcuni di questo è solo uscendo dall'inizio degli anni ' 80 e l'adozione di alcune versione moderna meccanismi di controllo, ma Git "ha fatto bene" nella maggior parte delle aree.

Non sono sicuro della misura della risposta che stai cercando, ma la nostra esperienza con Git è stato molto, molto positivo.

Answer 11

Utilizzo di Subversion con SourceForge e altri server oltre un certo numero di differenti connessioni medie squadre e la cosa funziona molto bene.

Answer 12

Io sono un grande sostenitore di fonte centralizzata di controllo per un sacco di motivi, ma l'ho fatto provare BitKeeper su un progetto per un attimo.Forse dopo anni di utilizzo di un modello centralizzato in un formato o in un altro (per Forza, Subversion, CVS) ho appena trovato distribuito controllo del codice sorgente di difficile utilizzo.

Io sono di mentalità che i nostri strumenti non dovrebbe mai ottenere nel modo del lavoro effettivo;si dovrebbe rendere il lavoro più facile.Così, dopo un paio di testa martellante esperienze, che ho salvato.Vorrei consigliare di fare alcuni davvero hardy prove con la tua squadra prima di smuovere le acque, perché il modello è molto diversa da quello che la maggior parte dei devs sono probabilmente abituati in SCM mondo.

Answer 13

Ho usato bazar per un po ' di tempo ora e l'amore.Banale ramificazione e la fusione indietro nel dare grande fiducia in uso di sedi, come devono essere utilizzati.(So che la centrale vcs strumenti devono consentire questo, ma i comuni inclusi subversion non consentono facilmente).

bzr supporta diversi i flussi di lavoro da solo, lavorando come un archivio centralizzato completamente distribuito.Con ogni ramo (per uno sviluppatore o una funzione) in grado di essere uniti in modo indipendente, le revisioni del codice può essere eseguita su un ramo di base.

bzr ha anche un ottimo plugin (bzr-svn) che consente di lavorare con un repository subversion.È possibile effettuare una copia del repo svn (che inizialmente vuole un po ' come si recupera l'intera storia del repository locale).È quindi possibile fare rami per funzioni diverse.Se si desidera fare una rapida correzione al tronco, mentre a metà strada attraverso la vostra caratteristica, si può fare un altro ramo, lavoro in, e poi unirsi di nuovo al tronco, lasciando la vostra metà caratteristica incontaminata e al di fuori del tronco.Meraviglioso.Lavoro contro la sovversione è stato il mio principale uso finora.

Nota l'ho usata solo su Linux, e soprattutto dalla riga di comando, anche se esso è destinato per funzionare bene su altre piattaforme, ha una interfaccia grafica come TortoiseBZR e un sacco di lavoro è stato fatto in materia di integrazione con Idi e il come.

Answer 14

Sto giocando intorno con Mercurial per i miei progetti a casa.Finora, quello che mi piace è che posso avere di più repository.Se prendo il mio portatile per la cabina, ho ancora il controllo di versione, a differenza di quando mi sono imbattuto in CVS a casa.La ramificazione è così facile come hg clone e di lavoro sul clone.

Answer 15

Utilizzo Di Subversion

Subversion non è distribuito, in modo che mi fa pensare che ho bisogno di un link su wikipedia nel caso in cui le persone non sono sicuri di cosa sto parlando :)

Answer 16

Utilizza darcs 2.1.0 e la sua grande per i miei progetti.Facile da utilizzare.Amore cherry picking modifiche.

Answer 17

Io uso Git al lavoro, insieme con uno dei miei colleghi.Le principali repository SVN, però.Spesso abbiamo a passare le workstation e i Git rende molto facile basta inserire le modifiche da un repository locale, su un'altra macchina.Quando stiamo lavorando come una squadra sulla stessa funzione, la fusione nostro lavoro è fatica.

Il git-svn ponte è un po ' traballante, perché quando si verifica in SVN riscrive tutti i commit per aggiungere la sua git-svn-id commento.Questo distrugge la bella storia di merge tra il mio collega repo di una miniera.Prevedo che ci non sarebbe usare un repository centrale a tutti, se ogni teammember potrebbe essere l'utilizzo di Git.

Lei non ha detto quello che so che si sviluppano su, ma Git ha lo svantaggio che devi utilizzare la riga di comando per ottenere tutte le caratteristiche.Gitk è una buona interfaccia grafica per visualizzare la cronologia di unione, ma la fusione deve essere fatto manualmente.Git-Gui e Visual Studio plugin non sono quel lucido di sicurezza.

Answer 18

Usiamo di controllo di versione distribuito (Plastica SCM) sia per multi-sito e scenari disconnessi.

1 - Multi-sito:se avete i gruppi lontani, a volte non è possibile fare affidamento sulla connessione a internet, o non è abbastanza veloce e rallenta gli sviluppatori.Quindi avendo indipendente del server, che può sincronizzare posteriore (in Plastica replica rami avanti e indietro) è molto utile e accelerare le cose.E ' probabilmente uno degli scenari più comuni per le aziende poiché la maggior parte di loro sono ancora interessato, di "completamente distribuito" pratiche in cui ogni sviluppatore ha la sua propria replicato repository.

2 - Scollegato (o veramente distribuito, se si preferisce):ogni sviluppatore ha la sua repository che viene replicata in avanti e indietro con i suoi coetanei o la posizione centrale.E ' molto comodo per andare a un cliente o semplicemente andare a casa con il vostro portatile, e continuare a essere in grado di passare i rami, check-out e check codice, guardare alla storia, eseguire annota e così via, senza dover accesso remoto "centrale" del server.Quindi ogni volta che si torna in ufficio, ti basta replicare le modifiche (normalmente rami) torna con un paio di click.