Iniziare con il controllo della versione

Devo implementare il controllo della versione, anche solo per lo sviluppo che faccio a casa. Ho letto di quanto sia stato fantastico Subversion negli ultimi due anni e stavo per dedicarmi ad apprendere questo sul lato fino a quando ho saputo che Git era il nuovo sistema di controllo della versione.

Data la situazione, dovrei tenere a bada e vedere quale esce in cima? Quali sono i loro vantaggi relativi?

Un problema che ho notato con Git è che non ci sono molte GUI complete, che è importante per molti utenti del mio team.

Inoltre, non mi dispiacerebbe suggerimenti su come iniziare con uno o l’altro. (tutorial, ecc.)

La cosa più importante riguardo il controllo della versione è:

SOLO INIZIARE A UTILIZZARLO

Non usare il controllo della versione è un’idea orribile. Se non stai usando il controllo di versione, smetti di leggere adesso e inizia a usarlo.

È molto facile da convertire

cvs<->svn<->git<->hg 

Non importa quale scegli. Scegli il più facile da usare e inizia a registrare la cronologia del tuo codice. È sempre ansible migrare a un altro (D) VCS in seguito.

Se stai cercando un GUI facile da usare su TortoiseSVN (Windows) e Versions (Mac) (Suggerito da codingwithoutcomments )


Modificare:

pix0r ha detto:

Git ha alcune caratteristiche interessanti, ma non sarai in grado di apprezzarle a meno che tu non abbia già usato qualcosa di più standard come CVS o Subversion.

Questo. Usare git è inutile se non sai cosa può fare il controllo della versione per te.

Modifica 2:

Ho appena visto questo link su reddit: Subversion Cheat Sheet . Buon riferimento rapido per la riga di comando svn.

Usa subversion, è facile da configurare, facile da usare e ha un sacco di strumenti. Qualsiasi sistema di revisione futuro avrà un’importazione dalla funzionalità SVN, quindi non è che non si possa cambiare strada se le esigenze crescono.

The Subversion Book è la soluzione migliore per imparare lo strumento. Potrebbero esserci altri tutorial di avvio rapido, ma il Libro è il miglior riferimento singolo che troverai.

Git ha alcune caratteristiche interessanti, ma non sarai in grado di apprezzarle a meno che tu non abbia già usato qualcosa di più standard come CVS o Subversion. Sono assolutamente d’accordo con i poster precedenti e inizio con Subversion.

Se sei nuovo su versioncontrol leggi questo:
Source Control HOWTO

Vai per SVN. Se non hai mai usato il controllo del codice sorgente in precedenza, non ti interesserà in un modo o nell’altro.

Inoltre, non vi è una grande quantità di apprendimento coinvolti nell’uso di un sistema di controllo del codice sorgente. Se ne impari uno, puoi facilmente passare a un altro in un secondo momento.

SVN è un ottimo strumento e dovrebbe occuparsi della maggior parte delle tue esigenze. E dal momento che è in circolazione, ha un discreto livello di strumenti GUI (TortoiseSVN, per esempio).

Vai per SVN.

Per una spiegazione amichevole della maggior parte dei concetti di base, vedere Una guida visiva al controllo della versione . L’articolo è molto SVN-friendly.

Ho usato RCS, CVS, SCCS, SourceSafe, Vault, perforce, subversion e git.

Ho valutato BitKeeper, Dimensions, arch, bazaar, svk, ClearCase, PVCS e Synergy.

Se dovessi iniziare un nuovo repository oggi, sceglierei git . Mani giù.

È gratuito, veloce e in fase di sviluppo attivo.

E puoi usarlo come client di qualsiasi repository di subversion usando git-svn.

Spacca.

@ superjoe30

Che ne dici di utilizzare il controllo del codice sorgente sul tuo computer, se sei l’unico programmatore? Questa è una buona pratica? Ci sono consigli o trucchi correlati?

Trovo che git sia in realtà più semplice per questo perché non hai bisogno di un server o preoccupati di inserire URL e così via. La tua roba di controllo delle versioni vive nella directory .git all’interno del tuo progetto e tu vai avanti e usalo.

Intro di 5 secondi (supponendo che tu l’abbia installato)

 cd myproject git init git add * # add all the files git commit 

La prossima volta fai qualche cambiamento

 git add newfile1 newfile2 # if you've made any new files since last time git commit -a 

Finché lo fai, git ti dà le spalle. Se si incasina, il codice è sicuro nel bel repository git. È meraviglioso

  • Nota: Potresti scoprire che le cose fuori git sono un po ‘più difficili che farle, ma è molto più preferibile avere quel problema che non avere affatto i file!

Dalla mia esperienza con esso, non consiglierei git come introduzione al controllo della versione. L’ho usato per un paio di mesi, e la mia impressione è che sia molto potente e – ora che in parte mi sono messo d’accordo – ragionevolmente intuitivo. Tuttavia, la curva di apprendimento è molto ripida, anche se ho usato il controllo della versione per anni. Soffre anche di essere troppo espressivo – supporta molti diversi flussi di lavoro e modelli di sviluppo, ma l’unica guida su “il modo migliore” per usarlo è alcune pagine in profondità nella ricerca di Google, il che rende anche difficile per un nuovo arrivato scegliere su.

Detto questo, è ansible che partire da una lavagna vuota con git sia effettivamente più semplice – la mia esperienza VCS è tutta con controllo di versione centralizzato (CVS, SVN, Perforce …) e una parte della mia (in corso!) Difficoltà con git è stata comprendere le implicazioni del modello distribuito. Ho guardato brevemente altri DVCS come Bazaar e Mercurial e sembravano un po ‘più amichevoli per i principianti.

Comunque, come altri hanno già detto, Subversion è probabilmente il modo più semplice per abituarsi alla mentalità di controllo della versione e ottenere un’esperienza pratica dei vantaggi di VCS (rollback, rami, sviluppo collaborativo, revisione più semplice del codice, ecc.).

Oh, e non iniziare con CVS. È ancora in uso pratico e presenta vantaggi, ma IMHO ha troppe peculiarità storiche e problemi di implementazione (commit non atomici!) Per essere un buon modo per imparare.

Il mio voto va a Subversion. È molto potente, ma facile da usare e ha alcuni ottimi strumenti come TortoiseSVN .

Ma come altri hanno già detto prima di me, APPENA INIZIARE AD UTILIZZARLO. Il controllo del codice sorgente è una parte così importante del processo di sviluppo del software. Nessun progetto software “serio” dovrebbe esserne privo.

Al mio attuale lavoro, il mio predecessore non ha utilizzato alcun tipo di controllo della versione. Ci sono solo montagne di cartelle in almeno 3 luoghi diversi in cui ha mantenuto tutti i suoi progetti. Ci si può aspettare che ogni cartella di progetto casuale trovi almeno un nome di cartella “project (OLD)” e uno denominato “project”

Con il controllo della versione, non devi mai fare copie di build “sicure”. Non devi davvero preoccuparti del tuo IDE che danneggia il file su cui stai lavorando (ti sto guardando, REALBasic 5.5) perché è così facile da impegnare (leggi: salva) il tuo lavoro ogni giorno.

Inutile dire che ho installato il controllo della versione il giorno dopo aver scoperto che esisteva.

Inoltre, TortoiseSVN rende il commit nel database facile come fare clic con il pulsante destro del mouse su una cartella.

Prova anche svn visivo per il tuo server se vuoi evitare qualsiasi lavoro da riga di comando.

Se sei su Mac OSX, ho trovato http://www.versionsapp.com/“>Versions come un incredibile front-end GUI (gratuito) per SVN.

Git è superiore alla sovversione, ma è un po ‘fuori bordo.

Direi, se hai appena iniziato, salta sul bordo; imposta un account gratuito @ http://github.com

Hanno materiale didattico sul sito per la creazione e l’utilizzo di git.

Non aspettare Scegline uno e vai con esso. Tutti i sistemi avranno i loro vantaggi e svantaggi. Il tuo potere potrebbe spegnersi, il tuo computer viene rubato, o ti dimentichi di annullare un cambiamento importante e tutto il tuo codice viene fritto mentre stai aspettando di vedere chi emerge vittorioso.

Non è così difficile passare tra i sistemi di controllo delle versioni. Come altri hanno già detto, l’importante è iniziare a utilizzare qualsiasi cosa il prima ansible. I vantaggi dell’utilizzo del controllo del codice sorgente rispetto all’utilizzo del controllo del codice sorgente superano di gran lunga i benefici differenziati tra i diversi tipi di controllo del codice sorgente.

Ricorda che, indipendentemente dalla versione del controllo sorgente che stai usando, sarai sempre in grado di eseguire una conversione forza bruta su un altro sistema posizionando i file dal vecchio sistema su disco e quindi importando quei file raw nel nuovo sistema.

Inoltre, avere familiarità con i fondamenti del controllo del codice sorgente è un’abilità molto, molto importante da avere come sviluppatore di software.

Usa TortoiseSVN (version.app se su mac). Basta installare e andare. Se hai bisogno di un posto per ospitare il tuo codice consulta http://beanstalkapp.com/

SubVersion è la scelta migliore per te, come ha sottolineato Karl Seguin. Il passaggio a un altro sistema di controllo delle versioni non sarebbe un problema. anche SVN ha molto da fare GUI facili da usare sul lato client (TortoiseSVN).

http://www.snee.com/bobdc.blog/2007/08/getting_started_with_subversio.html http://dojo.jot.com/WikiHome/Getting%20Started%20With%20Subversion

Se si sceglie di andare con subversion e si desidera ospitare il proprio server SVN, allora c’è un server basato su Windows molto carino e semplice chiamato server VisualSVN. Nasconde la complessità della creazione di un server Apache, in pratica basta andare avanti il ​​prossimo. La configurazione utente viene gestita con una webUI, invece di una configurazione

http://www.visualsvn.com/server/

l’utilizzo di un beanstalk di tipo public rlike è probabilmente più semplice, ma alcune persone preferiscono avere i propri repository, sia per la velocità che per la sicurezza

Quando ho deciso di utilizzare un sistema di controllo delle versioni del codice, ho cercato un buon tutorial su come iniziare, ma non ho trovato nulla che potesse aiutarmi.

Quindi ho semplicemente installato SVN Server e Tortoise SVN per il client e sono entrato nel deepend e non ho imparato come usarlo lungo la strada.

Inizia a utilizzare SVN per il tuo lavoro effettivo, ma cerca di guadagnare tempo con Git e / o Mercurial. SVN è ragionevolmente stabile per la produzione, ma alla fine ti troverai di fronte a uno scenario in cui avrai bisogno di un SCM distribuito, a quel punto sarai adeguatamente armato e i nuovi sistemi saranno abbastanza maturi.

Sì, SVN per preferenza a meno che tu non abbia davvero bisogno delle particolari caratteristiche di Git. SVN è abbastanza difficile; Sembra che Git sia più complicato con cui vivere. Puoi ricevere svn ospitato da persone come Beanstalk – a meno che tu non abbia persone Linux interne, lo raccomanderei davvero. Le cose possono andare male in modo orribile facilmente ed è bello avere qualcun altro il cui compito è risolverlo.

C’è un eccellente tutorial sul controllo delle revisioni di Eric Sink che vale la pena di leggere, indipendentemente dal sistema che usi.

superjoe30 scrive :

Domanda correlata (forse le risposte possono essere modificate per rispondere anche a questa domanda):

Che ne dici di utilizzare il controllo del codice sorgente sul tuo computer, se sei l’unico programmatore? >> è questa buona pratica? Ci sono consigli o trucchi correlati?

Uso SVN per tutti i miei progetti personali. Ho iniziato con l’esecuzione di svn sulla mia macchina domestica, ma alla fine sono passato a Dreamhost. I loro pacchetti di hosting che includono Subversion sono abbastanza ragionevoli.

Se su una finestra di Windows una slitta veloce e sporca è CVSNT. Facile da usare, basta impostarlo e funziona molto bene.

Io personalmente preferisco SVN, ma questo è un buon uso rapido.

Sicuramente sceglierei SVN su CVS, se non altro perché le persone che hanno imparato il controllo del codice sorgente usando CVS, tendono a usare ” svn delete ” quindi ” svn add ” invece di ” svn move “. Il che rende più difficile trovare tutte le revisioni precedenti di un file specifico. E puoi sempre aggiornare usando git-svn. Personalmente ritengo sia più facile imparare che hg, ma in realtà il motivo principale per usare SVN è che è diventato in gran parte il sistema di controllo delle versioni di Open Source Software.

Se hai intenzione di imparare / usare D è quasi obbligatorio accedere ai repository di terze parti, come DSource .

@ superjoe30 Sì, absoluteley. Una volta che inizi a utilizzare il controllo della versione, non torni mai indietro. Lo uso per tutto, anche per la mia cartella “home”.

@Orion Edwards Subversion non richiede un server. È ansible accedere direttamente a un repository locale (tramite un client, ovviamente) e non è coinvolto alcun processo del server.

Usa TortoiseSVN e puoi vivere anche senza conoscere i comandi di Subversion … Ma questo è male. Fortunatamente ci sarà sempre una “big opportunità” per impararle a memoria – quando il tuo prezioso repository viene corrotto.

Sì, succede.

Come già detto molte volte altrove, Just Do It. Sono stato in grado di iniziare da zero con Subversion sotto Windows in pochissimo tempo leggendo la guida rapida nel Red Book. Una volta ho indicato TortoiseSVN nel repository, ero in affari. Mi ci è voluto un po ‘per ottenere i punti più fini, ma erano solo gobbe da superare.

Suggerirei di installare il servizio Subversion invece di usare file: // URL, ma questa è principalmente una preferenza personale. Per un repository memorizzato sul tuo computer di sviluppo, file: // funziona correttamente.

Per esperienza personale, svn sarebbe la mia raccomandazione. Puoi anche utilizzare un servizio come Beanstalk che offre account gratuiti (con limiti ovviamente, ma sufficienti per qualsiasi progetto piccolo) per testare le acque. Ma come altri hanno già detto, git è superiore e probabilmente vale la pena esaminarlo.

Un consiglio importante per facilitare l’installazione di un server SVN adesso è utilizzare un dispositivo virtuale. Cioè, una macchina virtuale con subversion preinstallata e (principalmente) pre-configurata su di essa – praticamente una cosa plug & play. Puoi provare qui , qui e qui , o semplicemente provare a cercare su Google “subversion virtual appliance”.