2009-11-19 18 views
5

Sto per iniziare un progetto e stavo pensando di utilizzare Google Code per ospitarlo. Offre l'opzione di usare Mercurial o SVN per il controllo della versione. Non ho mai usato un VCS e vorrei sapere con chi è più facile lavorare.Quale VCS dovrei usare con Google Code?

Il progetto coinvolge due programmatori principali, ma pochi altri possono fornire piccole somme. È principalmente in python e utilizziamo Emacs come editor principale. Entrambi utilizziamo il sistema operativo Windows.

risposta

12

Utilizzare Mercurial.

Entrambi i sistemi saranno facili, ma Mercurial sarà veloce. Vuoi confrontare le differenze tra ciò che ha fatto qualcun altro la scorsa notte e ciò che hai fatto la scorsa notte? Con SVN ci vorranno un paio di secondi per file mentre parla ai server di Google. Con Mercurial sarà praticamente istantaneo.

Un paio di secondi per diff potrebbe non sembrare molto, ma i vantaggi di un'interfaccia scattante e reattiva diventeranno evidenti una volta che si utilizza un sistema che elimina (la maggior parte) di quelle pause.

Oh, e le persone possono sborsare il tuo progetto senza essendo un enorme dolore nel culo. Anche questo è bello.

MODIFICA: Mercurial non sente la necessità di schiaffeggiare una cartella .svn in ogni singola cartella del progetto. Queste cose sono brutte (e non nascoste di default su Windows, come se fossero su un sistema * nix). Ci sarà solo una cartella .hg nella radice del progetto, che è molto più pulita.

MODIFICA: un motivo in più per utilizzare Mercurial: hg bisect. Rintracciare un bug in 10 minuti invece di 2 ore perché sei riuscito a trovare la revisione esatta che lo ha causato è impressionante. Sembra che ci sia uno strumento Perl svn-bisect ma non è nel core, e la lentezza di SVN nell'aggiornamento tra le revisioni renderà il processo molto più lungo.

+0

Mercurial suona bene per me. Lo proverò. – Nikwin

+0

Mi piace poter creare cloni personali di altri progetti mercuriali su google code. –

1

Se non hai mai utilizzato un VCS prima, scegli uno dei due. Entrambi saranno più che sufficienti per le tue esigenze e dovrai imparare da zero.

Mercurial è decentralizzato come git, ma non mi preoccuperei troppo per un team di 2 programmatori, che non sono mai stati esposti al controllo del codice sorgente.

Prendi entrambi e dimenticati.

-1

Bene, penso che dovresti usare SubVersion. Non perché SVN sia in qualche modo migliore di Mercurial in termini funzionali, ma perché SVN è molto popolare e vi è molta documentazione (es. Un eBook gratuito) e alcuni ottimi plugin gratuiti (AnkHSVN per VS, TortoiseSVN per Windows Esploratore). Penso che la documentazione ti renderà rapidamente operativo, se non hai mai usato un VCS prima ...

HTH!

+4

C'è un libro Mercurial e TortoiseHg e il suo popolare ... – Murph

+1

Okay ... Volevo solo dire che stai meglio con SVN, se stai iniziando VCS da zero. Ha sicuramente i migliori strumenti e la documentazione disponibile, se sei un principiante ... –

1

La risposta semplice è SVN: accendi TortoiseSVN e TortoiseHg e vedrai che il primo è un po 'più avanti rispetto a quest'ultimo in termini di estetica e usabilità, tuttavia non penso che la semplice risposta sia abbastanza buona in questo caso.

Se inizierai a usare il controllo di versione per la prima volta sarei tentato (per tutto ciò che attualmente sono molto più a mio agio con SVN che Hg) suggerire che Mercurial è il modo migliore per andare. Distributed Version Control (DVCS) offre attualmente una maggiore flessibilità rispetto a Subversion con la sua dipendenza da un repository centrale. In particolare, la possibilità di eseguire il commit di codice locale non completo prima di inviare modifiche completate ai colleghi. Mercurial ha un "libro" in modo da avere una serie di linee guida su cui lavorare e ha una generale accettazione come strumento in modo che sia disponibile il supporto tra pari.

La mia preoccupazione principale per DVCS è che considero il controllo della versione incompleto senza un server separato (o almeno senza un repository non sulla tua casella di sviluppo) per vari motivi. Tuttavia in questo caso avremo un repository centrale ... quindi quell'argomento è meno valido.

Ho un problema secondario che penso che uno dovrebbe mirare a introdurre un server di integrazione continua (build e test) nei propri progetti alla prima opportunità, ma ancora una volta è qualcosa che può essere fatto con DVCS dato il condiviso/centrale repository.

io continuo a pensare che SVN ha un sacco da elogiare, il nostro repository lavoro è e rimarrà SVN per il prossimo futuro (notare che io sono quello che deve decidere!), Ma ugualmente io sono facendo le mie cose personali con Mercurial e imparando mentre vado.

+1

Yay, downvote senza commenti - sempre utile ... per quello che vale, questo è stato scritto quasi due anni fa, era proprio allora - TortoiseHg è decisamente migliore ora. – Murph

+0

Altri due downvotes * senza spiegazione * e, ho il sospetto, senza molto pensiero – Murph

1

Se non hai mai utilizzato un VCS, probabilmente avrai un momento difficile/facile con entrambi. Non penso che ci siano differenze di principio in questo. Una differenza importante tra questi due, tuttavia, è che SVN è centralizzato e Mercurial è decentralizzato.

Se lavori da dove non hai accesso alla rete (aerei, treni ecc.), un VCS decentralizzato ti permetterà di commettere le tue modifiche localmente prima di iniziare con le nuove modifiche. Successivamente ti sincronizzi con il repository centrale. Questo può essere utile.

Un VCS centralizzato non consente questo. Naturalmente, puoi ancora lavorare sul tuo codice, ma poiché non puoi effettuare il check-in tra le modifiche, dovrai impegnare le modifiche accumulate in una volta sola quando torni ad accedere al repository.