Domanda

Qual è il sistema di controllo del codice sorgente consigliato per un team molto piccolo (uno sviluppatore)?

Il prezzo non ha importanza.Il cliente pagherebbe :-)
Sto lavorando su Vista32 con VS 2008 in C++ e successivamente in C# e con WPF.Configurare un server (fisico) aggiuntivo per questo mi sembra eccessivo.

Qualche opinione?

È stato utile?

Soluzione

Vorrei usare Subversion (in effetti lo uso) [aggiornamento:Luglio 2014 - Utilizzo Git - vedi fine della risposta].SVN è:

  • gratuito,
  • abbastanza buono (vedi svantaggi di seguito),
  • semplice,
  • funziona bene su Windows (e anche Linux),
  • molte persone lo usano quindi è facile ottenere aiuto,
  • può integrarsi con la maggior parte degli IDE, ad es. Studio visivo (cioè. ankhsvn O VisualSVN -- Ulteriori informazioni) O Eclisse (cioè. Sottoclip -- Qui qualcuno lo ha chiesto).

Vorrei fortemente macchina separata consigliata per il server di controllo del codice sorgente.Nella migliore delle ipotesi da qualche parte sulla nuvola.Vantaggi:

  • Non perdi i repository del controllo del codice sorgente se la tua casella di sviluppo muore.
  • Non devi preoccuparti della manutenzione di un'altra scatola.

Ci sono aziende che ospitare repository SVN.

Qui sono collegamenti a pacchetti SVN (client e server) per vari sistemi operativi.

Svantaggi dell'SVN

Utilizzo SVN su computer Windows da circa 5 anni e ho scoperto che SVN presenta alcuni svantaggi :).

È lento su repository di grandi dimensioni

SVN (o il suo client -- TortoiseSVN) ne ha uno grande svantaggio: è terribilmente lento (durante l'aggiornamento o il commit) su repository di grandi dimensioni (migliaia di file) a meno che tu non abbia SSD guidare.

La fusione può essere difficile

Molte persone si lamentano di quanto sia difficile la fusione con SVN.

Faccio la fusione per circa 4 anni (inclusi circa 2 anni in CVS - è stato terribile, ma fattibile) e circa 2 anni con SVN.

E personalmente non lo trovo difficile, d'altra parte, qualsiasi unione è facile dopo aver unito i rami in CVS :).

Ungo repository di grandi dimensioni (due repository in effetti) una volta alla settimana e raramente ho conflitti difficili da risolvere (la maggior parte dei conflitti viene risolta automaticamente con diff software che utilizzo).

Tuttavia, nel caso di progetti di più sviluppatori, la fusione non dovrebbe costituire alcun problema se si rispettano alcune semplici regole:

  • unire le modifiche spesso,
  • evitare lo sviluppo attivo in vari rami contemporaneamente.

Aggiunto nel luglio 2011

Consigliato da molti sviluppatori Controllo della versione distribuito Piace Idiota O Mercuriale.

Da singolo sviluppatore prospettiva ci sono solo alcuni importanti vantaggi del DVCS rispetto all'SVN:

  • DVCS può essere più veloce.
  • Puoi impegnarti nel repository locale senza accedere a quello centrale.
  • Il DVCS è una cosa interessante e fantasiosa da usare/imparare (se qualcuno paga per il tuo apprendimento).

E non credo che la fusione sia un problema in caso di singolo sviluppatore.

Joel Spolsky ha scritto tutorial su Mercurial che vale sicuramente la pena leggere.

Quindi, nonostante i molti vantaggi di DVCS, resterei con SVN se la fusione o la velocità non fossero un problema.

Oppure prova Mercurial, che secondo Questo E Questo SO domande, è meglio supportato (a luglio 2011) su Windows.

Aggiunto nel luglio 2014

Per circa un anno utilizzo Git (principalmente Git Bash) per i miei progetti domestici (ad es.risolvere i problemi di Eulero) e i rami locali per ciascun problema di Eulero sono una caratteristica davvero interessante, esattamente come viene descritto come vantaggio di DVCS.

Oggi gli strumenti Git su Windows sono molto, molto migliori rispetto a 2 o più anni fa.Puoi usare Remote Repo (come GitHub o ProjectLocker e molti altri) per tenere la copia del tuo progetto lontano dalla tua workstation senza sforzi/denaro extra.

Tuttavia uso solo il client GUI per guardare diffs (e talvolta per scegliere i file da commettere), quindi è meglio non aver paura della riga di comando: è davvero bello.

Quindi da oggi andrei con Git.

Altri suggerimenti

Consiglierei anche Mercurial.Il suo set di comandi è molto simile a quello di Subversion, quindi la curva di apprendimento non è così ripida.Come accennato in precedenza, è progettato per essere eseguito localmente, ma è anche facile condividere/unire le modifiche tra computer o anche semplicemente inviarle a un server remoto per i backup.

Offre strumenti eccellenti, come TartarugaHG, e ha buoni plugin per NetBeans ed Eclipse.Funziona anche in modo nativo su Win32, poiché è scritto in Python.

Se non vuoi configurare tu stesso un server (ad esempio per i backup), sono disponibili provider di hosting gratuiti;c'è un elenco completo su Il Wiki Mercuriale.

Lo consiglio vivamente idiota

Funziona alla grande sia per i team grandi che per quelli piccoli.L'unico inconveniente è lo scarso supporto nativo di Windows.Anche se funziona bene per me in Cygwin.Esiste anche a porta Windows nativa.

Alcuni dei suoi vantaggi:

  • Ottimo supporto per un flusso di lavoro non lineare.La sua ramificazione e fusione è di gran lunga migliore rispetto ad esempio a Subversion.
  • Buoni strumenti per navigare nel tuo repository
  • Gestisce bene progetti di grandi dimensioni.
  • Non è possibile modificare la cronologia senza cambiare la firma crittografica del tuo repository
  • Grazie al suo design non monolitico, è facile scrivere script.

Alcune persone ritengono che la curva di apprendimento sia ripida.Ma una volta che lo capisci, puoi fare quasi tutto ciò che desideri con esso.

Scegli subversion e tortoiseSVN, non è necessario configurarlo su un server.

  • I costi sono pari a zero
  • La documentazione di sovversione è fantastica e divertente da leggere
  • tortoiseSVN è un client molto conveniente

La Cripta di Sourcegear è un'ottima opzione, funziona su SqlServer ed è in circolazione da molti anni.Non utilizzerei alcuna versione di VSS (Visual Source Safe).

Subversion ha barriere all’ingresso molto basse.

TartarugaSVN è un client gratuito e si integra nel tuo Explorer, ad es.nel menu cliccabile con il tasto destro del mouse.

Il repository può essere semplicemente una directory da qualche parte sul tuo PC o su un'unità di rete.Fare il backup significa semplicemente comprimere questa directory

Esistono alcuni plug-in per Visual Studio per Subversion, AnkSvn è quello che ho usato, è gratuito e si integra bene (cioè sarà intelligente nello spostare ed eliminare file, ecc.)

Subversion è una buona scelta per uno sviluppatore.

Aggiornamento:

Da questo post utilizzo Mercurial.È un SVN distribuito.L'aspetto "distribuito" potrebbe non essere direttamente utile per un unico sviluppatore, tuttavia è migliore per la fusione ed è un po' più veloce.C'è anche un client di estensione gratuito ed efficace per Windows Explorer: Tartaruga Hg.

Quindi, in sintesi, se sei il tipo di persona che lavorerà su più rami contemporaneamente (eseguendo picchi, ecc.) o se lavori su più PC contemporaneamente e desideri l'accesso offline completo alla cronologia di controllo su entrambi, allora Mercuriale.Se desideri solo un monitoraggio semplice e una soluzione ben collaudata e di facile comprensione, allora Sovversione.

Sono sorpreso che nessuno ne abbia parlato Per forza.È gratuito per 2 persone, incredibilmente veloce e si integra con VS.Anche server di origine ha dei collegamenti per impostazione predefinita.

Oltre al controllo del codice sorgente, vale davvero la pena completare il ciclo e impostare a server dei simboli e un server di origine, in modo da avere un semplice debug di tutto ciò che hai spedito (ad es.non sarà più necessario cercare pdb o sorgenti che corrispondano al file binario).Sia il server sorgente che quello dei simboli sono completamente gratuiti e supportati in VS dal 2005.

Puoi utilizzare Vault da SourceGear, IL strumento sostitutivo per la sicurezza della fonte dello studio visivo.L'IDE è integrato in Visual Studio.

Lo strumento è gratuito per singolo utente.

Maggiori informazioni: http://www.sourcegear.com/vault/index.html

Io uso Mercuriale.Funziona a meraviglia in modalità standalone sul mio sistema di sviluppo Vista senza che siano necessarie altre dipendenze.Io uso la riga di comando ma c'è anche TartarugaHG da integrare con Explorer.

Due commenti:

  1. Esistono altri strumenti che probabilmente si integrano meglio con VS.Penso che Subversion abbia dei bei plug-in VS.
  2. Il vantaggio di un server separato è che è un bel backup di tutto il tuo lavoro nel caso in cui il tuo HDD muoia, ecc.quindi sconto averne uno.

Modificare: @Slartibartfast: se desideri semplicemente eseguire il controllo del codice sorgente su una singola macchina, uno strumento di controllo del codice sorgente distribuito come git o Mercurial è l'ideale poiché sono progettati per eseguire repository completi su una macchina senza il sovraccarico di un server.Il fatto che non colleghi mai il tuo repository a quello di qualcun altro per eseguire push e pull delle modifiche non significa che lo strumento non sarà corretto.

Esistono due possibili soluzioni al tuo problema:VCS centralizzato o VCS distribuito (DVCS).

VCS centralizzato come Subversion soddisferebbe le tue funzionalità per il commit e la navigazione nel registro.Ti consente inoltre di archiviare in modo sicuro il tuo repository su un altro computer, il che dovrebbe essere uno dei tuoi obiettivi principali poiché il guasto del disco rigido è sempre una possibilità.Tuttavia, utilizzando Subversion la cronologia risiede ancora solo nella posizione centrale rendendola vulnerabile e hai dichiarato di non voler avere un altro server.

I sistemi di controllo della versione distribuiti (DVCS) come Mercurial e Git ti consentono di eseguire operazioni più complesse sul tuo repository.Con entrambi questi strumenti l'intero repository risiede sullo stesso computer, rendendo un po' più semplice eseguire i backup e utilizzare il repository con un altro computer, ad es.computer portatile.Anche se all'inizio Mercurial potrebbe sembrare complesso, le operazioni che utilizzeresti con subversion sono praticamente le stesse con Mercurial.Pertanto non ci sono costi aggiuntivi per iniziare se conosci già Subversion e potrai facilmente utilizzare le funzionalità più avanzate di Mercurial in seguito.

Dovresti essere in grado di trovare un servizio di repository online per il tuo repository Mercurial che ti consenta di eseguire facilmente backup e collaborare un giorno, se ne avrai bisogno.

Il mio consiglio è Mercurial con TortoiseHg.

A un sistema di controllo del codice sorgente non importa se è coinvolto un solo sviluppatore :)

Ti consiglierei di utilizzare un sistema di controllo del codice sorgente che hai già utilizzato e che ti è piaciuto.
Se ti piace l'integrazione del sistema di controllo del codice sorgente rispetto al 2008, preferirei comunque TFS anche se non ho mai avuto l'esperienza per configurarlo, ma non dovrebbe essere così difficile.

Un'altra possibilità è usare svn (troverai alcuni server su google) e use Tartarughevn che si integra nella shell di Windows ed è piacevole lavorarci.

Numerosi post sostengono di mettere il repository su un server perché fornisce ridondanza.Non penso che questo sia molto utile per un singolo utente.L'utilizzo di una macchina server separata aggiunge molta complessità, ma non comporta molta ridondanza:se perdi la macchina server, hai ancora i sorgenti attuali sulla tua macchina di sviluppo, ma potresti aver perso TUTTA la cronologia.Mettere il repository su un server ha senso se viene eseguito regolarmente il backup di quel server.L'utilizzo di un servizio di hosting esterno per il repository può fornire ridondanza di archiviazione, ma sei in balia del servizio esterno E hai bisogno di una connessione Internet per accedere al repository.Se utilizzi un host esterno, esegui backup frequenti del repository di cui mantieni il controllo!

Personalmente consiglierei TortoiseSVN utilizzando un repository basato su file locale.Assicurati solo di eseguire regolarmente il backup del repository locale su una seconda macchina o su un supporto esterno (come i CD-ROM).

Consiglierei due cose:

Innanzitutto, l'altro server: cosa succede se la tua macchina muore?la casa brucia?eccetera.Averlo su un'altra macchina è una buona idea dal punto di vista della ridondanza.

La seconda è COSA:

Se hai molta familiarità con le fonti visive (non) sicure, pensa a SourceGearVault.È MOLTO bello, molto veloce e un "clone" notevolmente migliorato di VSS (cioè funziona allo stesso modo dal POV degli utenti, non sotto il cofano).Richiede server SQL e Windows (è .NET + SQL server).Gratuito per 1 utente.

Se non lo sei, allora ti suggerisco di fare una delle due cose:

Per prima cosa, procurati VisualSVN.È fantastico, funziona davvero bene con VS2008.In secondo luogo, se DEVI eseguirlo localmente, ottieni il server VisualSVN (gratuito!).Assicurati di avere un buon piano di riserva.Funziona su XP/2003/2008/Vista ecc. Sotto il cofano c'è solo Apache + SVN, quindi ti fa risparmiare solo sulla configurazione: mi ci sono voluti 5 minuti per installarlo e farlo funzionare.

OPPURE, e preferisco questo:

vai da qualche parte come Unfuddle, Dreamhost ecc. e ottieni hosting per SVN.È privato, è veloce e, soprattutto, è FUORI SEDE.Il mio account dreamhsot, con qualcosa di pazzesco come 500 GB di spazio di archiviazione e 1-2 TB di trasferimento al mese, costa circa $ 6 al mese!Ce ne sono altri che fanno hosting SVN + tracciamento dei bug ecc.Guardati intorno.

Ma sì, SVN è schizzzznit. Potresti creare un repository locale, ma mi piace avere un server remoto di cui è stato eseguito il backup.

TFS è totale, eccessivo per 1 sviluppatore (o <5 IMO)

Mi rendo conto che il costo non è un problema, ma una bella soluzione gratuita che non comporterebbe il check-in e il check-out sarebbe quella di ospitare il codice all'interno Dropbox in questo modo otterresti immediatamente il controllo delle versioni e il backup, che sono le funzionalità principali che un singolo sistema di sviluppo fornirebbe.

Bazar è un buon sistema di controllo della versione.Mi piace usarlo per le mie configurazioni Linux perché non è necessario creare un repository separato.

Qualche tempo fa ho pubblicato un post sul blog con istruzioni sull'utilizzo di SVN con un solo sviluppatore.L'ho chiamato Controllo del codice sorgente a porzione singola

Bene, per cominciare, non ne hai bisogno distribuiti :) Non sono sicuro di cosa significhi questa parte fisica, perché potresti mettere SVN Server sulla tua macchina in pochi problemi.

D'altra parte, NetBeans dispone di un modulo di cronologia locale che registra tutte le modifiche locali di un file.Forse qualcosa del genere ti basterebbe se Visual Studio avesse qualcosa di simile.

Consiglierei Subversion poiché è per un singolo sviluppatore e presumo che tu non stia eseguendo unioni complesse e molti controlli di registro/cronologia.

Sembra che molte persone lo stiano usando http://svnrepository.com/ per il loro hosting.Viene fornito con Trac e persino Git se ne avrai bisogno in seguito.

Alcune buone risposte qui.

Voglio ribadire il suggerimento di utilizzare un computer separato per ospitare il server di controllo del codice sorgente, anche se non deve essere un dedicato macchina.Potrebbe essere il tuo box Windows Home Server o qualche altro server che stai già utilizzando.Oppure potrebbe essere una macchina virtuale ospitata su qualche altro server.In ogni caso, rendilo separato dalle macchine in cui scrivi il codice.

Voglio anche suggerirti di ottenere una buona disciplina di backup per il tuo server.Almeno qualcosa di sera;ogni ora se puoi.Esegui il backup su un dispositivo dedicato (come un disco rigido esterno) o qualcosa fuori sede (un server a casa di tuo cugino in un altro stato) o nel cloud (Amazon S3).Ricorda che il tuo codice sorgente è la tua risorsa chiave;Prenditene cura!

Ho lavorato con Bazar ormai da qualche settimana e mi piace davvero.Sono uno sviluppatore Linux quindi non so molto di Tortois ma se ti piace dovresti sapere che esiste un Tortoisbzr

Senza dubbio userei git, e credo che molti motivi per cui un singolo sviluppatore vorrebbe usare git siano suggeriti o descritti in vai magia

Io uso Springloops - strumento di controllo della versione per gli sviluppatori

  1. Controllo della versione SVN/Git
  2. Distribuzione automatica sui server
  3. Creare repository
  4. Invita persone
  5. Importa file
  6. Grande supporto

Quindi, prova Springloops

Non vedo perché il fatto che il tuo sviluppatore cambi qualcosa sul problema del controllo del codice sorgente.Seguirei lo stesso sistema (in effetti lo faccio nei miei progetti solisti).Io uso wush.net (svn e trac) in questi casi.È veloce da configurare e non richiede che tu stesso faccia o conosca eventuali problemi del server.Ti consiglio di usare qualcosa di simile.

Consiglierei di usare sovversione.Molti hanno consigliato di utilizzare una scatola separata come server, nel caso in cui la tua macchina di sviluppo muoia.Cosa succede quando il server SVN muore?La risposta qui è che, indipendentemente da dove si sceglie di eseguire il server, assicurarsi di eseguire sempre backup frequenti, possibilmente automatizzati quotidianamente su qualche macchina secondaria, preferibilmente fuori sede.

Uso Perforce anche per le mie cose personali, principalmente perché lo usiamo al lavoro.Ci sono anche collegamenti emacs per questo, quindi puoi sincronizzare, archiviare o estrarre materiale, ecc.tutto da emacs.

Recentemente ho trasferito il mio studio da Subversion a Perforce e ho messo alcune note a riguardo, una sorta di post mortem, sul mio blog Qui.Spero che sia utile.

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