Dovrei guardare i sistemi di controllo della versione oltre Subversion?

StackOverflow https://stackoverflow.com/questions/224396

Domanda

Nell'ultimo anno sono diventato dipendente dalla sovversione. Sono uno sviluppatore unico e lavoro anche su alcuni dei miei progetti. Con SVN è davvero facile gestire tutto - e poiché è ospitato su un server online tramite HTTPS, posso accedere al mio codice da qualsiasi luogo. È ottimo anche per la distribuzione di codice sui nostri server di produzione / sviluppo.

Il mio punto è che fa tutto ciò di cui ho bisogno e che non mi ha mai deluso.

C'è qualcosa di meglio? Mi sto perdendo alcune funzionalità in un altro prodotto che potrei utilizzare per semplificarmi la vita? Mi occupo sempre di utilizzare il miglior software in circolazione e non ho problemi a migrare verso le nuove tecnologie.

Ho sentito parlare di GIT e ho fatto delle ricerche. Ho intenzione di provarlo, ma mentre ci sto giocando, ci sono altri sistemi di controllo della fonte che sono considerati "standard di settore". e fanno le cose meglio di SVN?

È stato utile?

Soluzione

Git, Mercurial e Bazaar sono sistemi di controllo distribuiti che operano dell'idea che non sei sempre connesso alla rete e che non è necessario che vi sia una versione centrale del repository.

Se stai facendo un sacco di lavoro distaccato, a volte chiamato "modalità aereo", come in un aereo e non puoi impegnarti, dai un'occhiata a Bazaar. Ho trovato più facile acclimatarsi rispetto a Git o Mercurial.

Se lavori sempre connesso alla rete e sei l'unico sviluppatore, probabilmente puoi rimanere con Subversion.

Inoltre, considera il valore di mantenendo la tua directory home in Subversion .

Altri suggerimenti

Mercurial

Ho usato principalmente CVS e SVN, felice e contento, quindi ho iniziato a ricercare il controllo del Distributed Source in quanto si sono fatte molte storie su DSVC. Dopo aver usato DSVC ho notato un cambiamento nel mio stile di sviluppo, sono diventato più fluido e adattabile. Consentendomi di fondermi indolore nel tronco o nel ramo sperimentale.

  • Mercurial può scalare da una banda di un solo uomo a un enorme OpenJDK, senza molto mal di testa.
  • Mercurial è veloce, forse non veloce come GIT, ma è ancora molto veloce
  • Mercurial Queues è un modo fantastico di gestire le patch. Alla velocità dell'illuminazione ingrassata.
  • Può essere eseguito su diversi sistemi operativi, la compatibilità è ottima in quanto si basa su Python.
  • la curva di apprendimento è più bassa di GIT, dopo che alcuni documenti leggono ottieni il jist di base delle cose ( http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ )
  • hg ti permette (così come molti DSVC) di interfacciarti con un controllo Sorgente SVN aziendale con hg-svn e hgsubversion che è una meravigliosa estensione con permessi e checkout, ma non ancora spingere o eseguire il commit della funzionalità
  • È inoltre possibile configurare un server HTTP eseguendo push e pull tramite SSH
  • ha anche un'opzione davvero ordinata di stare insieme ai tuoi compagni di codifica e semplicemente avviare il server HTTP eseguirlo su localhost e i tuoi compagni possono spingere e tirare mentre fai uno sprint di codice.
  • È inoltre possibile visualizzare lo stato corrente del progetto tramite questa pagina HTTP.
  • infine cerca una breve descrizione dei semplici comandi ( http: // edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf )

Git

  • l'ho provato, il suo supporto per svn è migliore di mercurial. ma dal momento che hgsubversion è in aumento e sta diventando concorrenza per git svn.

Git è interessante, ma è necessario mantenere costantemente il depo del codice sorgente e reimballarlo. Dato che è composto da molti script bash, ha problemi a funzionare su Windows. Ma è incredibilmente veloce, con molte funzionalità da usare. In realtà la quantità di funzionalità può essere uno svantaggio.

BZR

  • non l'ho mai provato

Non ho più guardato indietro da quando ho iniziato con HG

Personalmente starei con Subversion. Da un punto di vista professionale ho visto molti più posti di lavoro che chiedono (e sanno) quale Subversion è stato confrontato con GIT. Inoltre ci sono molti strumenti open source e freeware costruiti attorno a Subversion, per non parlare dell'enorme comunità di Subversion.

Il controllo del codice sorgente non è sempre l'ultimo e il più grande, ma più spesso riguarda ciò che è provato e vero.

Il miglior motivo per cambiare è la necessità. Tuttavia, sembra che non sia necessario cambiare. Sei un " Army of One " quindi la maggior parte delle potenti funzionalità non si applicano alla tua situazione. Sì, le persone discuteranno con me su questo, tuttavia spingeranno questa funzione o quella funzionalità che molto probabilmente non ti serve davvero. Il tempismo è tutto, se in futuro le tue esigenze cambiano, allora cambia la tua soluzione.

Ci saranno sempre soluzioni migliori o diverse per uno spazio problematico, in questo caso il controllo del codice sorgente, tuttavia è necessario bilanciare lo sviluppo personale, i miglioramenti di processo / pratica e la consegna del prodotto di lavoro. Potresti saperne di più sulle diverse soluzioni / applicazioni per il controllo del codice sorgente per espandere le tue conoscenze per riconoscere quando è il momento di cambiare soluzione ma attenersi a ciò che funziona per ora.

Ecco 3 motivi per passa a git da Subversion (da MarkMcB):

  • Filiali locali infinite, facili, non basate su file system
  • Stashing lavoro temporaneo
  • Collaborazione prima degli impegni pubblici

(Leggi l'articolo collegato per spiegazioni complete e confronti diretti su come fare le tre cose sia in git che in Subversion.)

Anche io personalmente starei con Subversion, C'è qualcosa di meglio?

Subversion è un ottimo sistema di controllo della versione e ne sei soddisfatto, quindi se stai guardando oltre, posso consigliarti di ottenere alcune informazioni su Integrazione continua , ci sono molti strumenti là fuori che possono aiutarti a creare build automatiche, a testare le tue build, a verificare l'integrità di ogni commit e molto altro ancora. ..

Anche Mercurial merita considerazione; la ramificazione è molto più amichevole e può funzionare senza una connessione di rete. Non ho mai provato seriamente a separare il lavoro in rami fino a quando non sono passato da SVN a Mercurial.

L'unica cosa che mi manca seriamente è TortoiseSVN; c'è un workalike (TortoiseHg) che è abbastanza buono, ma non è lo stesso ..

In ogni caso, creare un repository Mercurial da uno SVN è banalmente facile ... provalo e vedi se ti si addice o no.

Regola n. 1: " Non modificare mai un sistema in esecuzione "

Inoltre, poiché ci sono molte nuove soluzioni brillanti (per problemi che non hai, mentre lavori da solo) dovresti considerare il costo del passaggio a un nuovo VCS: L'importazione di sovversione in Mercurial / git non è un compito facile

non esiste uno strumento (AFAIK), che importa i repository svn usando il dumpformat. Quindi se non usi il dumpformat ti atterrai a controllare tutti i rami / tag da svn e aggiungerli a git / BZR / Mercurial manualmente / tramite script

Quindi non so quanto siano grandi i tuoi repository (i miei repository vanno da 20 MB a 24 GB), ma ci vorrà molto tempo per verificare un intero repository e anche piccoli progetti con molti tag consumeranno molto spazio su disco rigido .

Un ulteriore problema è il tempo fino al termine della migrazione per cui non è possibile continuare a lavorare.

Sono proprio come te nella questione delle indagini costanti al fine di ottenere lo strumento migliore.

Ho provato SVN per il lavoro SOLO e qualcuno mi ha consigliato Mercurial (hg). Ora faccio note a riguardo. È più amichevole di Git in Windows. Ora penso che "perché svn complica un compito semplice come i tag". SVN non sa cosa sia un tag. Per SVN un tag è una copia. In mercurial un tag è un alias per una revisione. Quanto potrebbe essere complicato?

Le prestazioni sono un altro problema. In Mercurial il tuo repository è nella tua macchina locale. Quindi è molto veloce per un registro, diff o cronologia.

Anche se non so nulla dei server che supportano mercurial per una versione online del tuo repository.

Se SVN risponde a tutte le tue esigenze, non vedo il motivo del cambiamento. Se la curiosità è il motore della tua ricerca di un diverso controllo del codice sorgente, allora consiglierei di leggere su git o altra soluzione scm distribuita e provare a capire se vale la pena l'investimento per cambiare (che dubito sia nella tua situazione).

C'è un vecchio proverbio yankee.

Se non è rotto, non aggiustarlo.

Vale sicuramente la pena esaminare " distribuito " VC anche se non stai effettivamente utilizzando un flusso di lavoro distribuito. Essere in grado di avere filiali private e il controllo degli impegni locali vale lo sforzo di apprendere git. Ho usato principalmente git-svn (con altri membri del team che utilizzano client SVN normali, quindi abbiamo avuto un normale flusso di lavoro centralizzato) e ha funzionato in modo impeccabile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top