Stiamo avviando un nuovo team di dimensioni molto ridotte (diciamo 2-5) la mia domanda è: quale tipo di controllo versione funziona meglio per questo tipo di team, sia centralizzato che distribuito.
Stiamo avviando un nuovo team di dimensioni molto ridotte (diciamo 2-5) la mia domanda è: quale tipo di controllo versione funziona meglio per questo tipo di team, sia centralizzato che distribuito.
Risposte:
Distribuito fino in fondo, non c'è davvero più alcun punto per IMHO centralizzato, specialmente se si parla di sviluppo di un team.
Un altro voto per Mercurial, nessuna seccatura da installare sotto windows e bitbucket.org ha repository gratuiti (che possono essere privati) con spazio illimitato.
Se hai intenzione di lavorare su un progetto open source, git e Github sembrano essere più adeguati / popolari. Tuttavia, se non ti sei avventurato nei DVCS, ti consiglio di iniziare con Mercurial e questa fantastica guida .
quello che userete tutti in modo coerente
[personalmente, mi piace Mercurial]
Probabilmente la risposta migliore è "qualunque cosa tu sia a tuo agio". Anche quando lavoro su cose personali, uso Git. Sembra fare un buon lavoro di ridimensionamento sia su che giù e la mia esperienza limitata con Mercurial è più o meno la stessa.
Penso che dovresti scegliere qualunque cosa tu sia a tuo agio. In un piccolo team, non avrai diversi alberi di codice (come il kernel Linux), quindi un repository centrale è OK. Ma puoi avere questa configurazione anche con VCS distribuito. Quindi andrei con popolarità ed esperienza personale. Popolari sono SVN, git e Mercurial. Dovresti decidere quale di essi è meglio utilizzato con il tuo team (esperienza, supporto degli strumenti nel tuo IDE scelto, ecc.).
Dipende davvero dal fatto che i tuoi sviluppatori sviluppino o meno un sacco di codice offline o meno, ma solo per scegliere tra un repository distribuito o centralizzato, poiché questa è la prima cosa che dovresti decidere. Quindi, se decidi che un approccio centralizzato funziona meglio di SVN è tutto ciò di cui hai bisogno. D'altra parte, se si sceglie un approccio distribuito rispetto a quello di git, anche su Windows è abbastanza buono poiché ora si ha git di tartaruga (la stessa interfaccia che esiste anche per svn). Inoltre, non contare così tanto sul supporto IDE perché potresti avere una brutta sorpresa se mai lo usi, e potresti scoprire che i file che non dovrebbero essere impegnati vengono impegnati a tuo nome dall'IDE.
Chiedi alla tua squadra se qualcuno vuole occuparsene. È molto meglio avere un sistema stabile e una persona responsabile, piuttosto che un buon sistema quando nessuno se ne preoccupa e nessuno è in grado di ripristinarlo dal backup.
Se esiste una persona del genere, saprà già cosa usare, quindi accetta la sua decisione. In caso contrario, ottieni una soluzione ospitata. Sarebbe molto stupido provare GIT (uno dei migliori) se tutti gli sviluppatori non toccassero mai Shell / Linux.
Dipende anche dal numero di persone "non tecniche", che devono leggere / contribuire. Assicurati solo che possano usarlo e ci sono strumenti disponibili.
SVN è ampiamente supportato negli strumenti. Gli utensili sono la chiave; persone diverse avranno abilità diverse. Alcuni preferiranno la riga di comando, altri preferiranno strumenti basati su IDE, altri preferiranno strumenti grafici. Al momento SVN sembra essere lo strumento più ampiamente supportato.
Altro che Mercurial o Git.
Penso che nelle piccole aziende ci siano argomenti per centralizzare alcune cose. (Pensa ad esempio al backup fuori sede. Quando hai solo 2 persone che lavorano su un progetto e stanno alloggiando nello stesso edificio e c'è un incendio, la decentralizzazione di tutti e due i computer potrebbe non essere sufficiente.)
Tuttavia: avere una soluzione parzialmente centralizzata non ti limita a un sistema centralizzato. Puoi semplicemente passare a un server esterno con qualcosa come git o mercurial.