Solo alcuni pensieri, non organizzati.
Se i tuoi amici sono già abituati a gettare, Git è un buon e robusto SCM distribuito, con ottimi servizi di hosting disponibili, come Github o Gitorious.
Tuttavia, i concetti Git non sono facili da comprendere. Fossil ha concetti simili, ma è probabilmente più facile da iniziare (nessuna area di staging, nessun concetto di indice, ripristino delle modifiche dall'ultimo commit con revert non reset o checkout, ecc.). Non ci sono una miriade di sottocomandi con i pletora di opzioni, l'aiuto è conciso e chiaro. Se temi di essere perso, scegli un fossile. Naturalmente, questo significa anche che con fossili non puoi fare tante cose come con git (non basti pensare ad esempio, almeno non per il momento).
Per i fossili, ci sono few hosting online services available. È facile come con Git configurare un server per eseguire Fossil.
Inoltre, con Fossil, la cronologia di un progetto viene archiviata in un singolo file, quindi trovo molto semplice eseguire il backup di tutti i progetti: inserire tutti i repository nella stessa cartella e creare un'unica attività rsync. Tuttavia ciò rende totalmente inutili i backup incrementali .
Mentre con git, lavorando su due rami sugli stessi progetti in diverse cartelle significherebbe avere due copie di tutta la storia del progetto e filiali in due distinti .git/objects directory che possono essere ridondanti e enorme, con Fossil lo schema di lavoro predefinita è avere un singolo repository e una o più directory di lavoro connesse ad esso. Forse se l'utilizzo del disco è importante, ciò avrà importanza.
Attenzione, inseguitore di bug di fossili (sistema di ticket in gergo) e wiki sono piuttosto rudimentali (anche se funzionano bene).
I cloni Git sulla stessa partizione creeranno, per impostazione predefinita, collegamenti fissi. Quindi l'unico spazio necessario è l'albero di lavoro – knittl
@Benoit, si noti che 'rsync' -ing Fossil repos è un approccio un po 'ingenuo in quanto non richiede alcuna attività di scrittura su quel file di database al momento del backup. L'unico approccio robusto per fare backup "online" è l'uso di 'sqlite3 dump ... 'e il backup dei file di dump in seguito. E Git non è poi così difficile da eseguire: devi solo usare Git per svolgere questo compito. Inoltre, se si ha bisogno di una soluzione di alto profilo gitolite v3 implementa la replica master/slave su push. – kostix
@kostix: alle persone piace eseguire backup bit a bit per diversi motivi. Anche se non vedo alcun motivo legittimo per eseguire il backup bitwise di un repository di fossili e non fare una discarica sqlite3, alcune persone saranno riluttanti ad esso. Inoltre, il fossile ha la replicazione, ma non replicherà alcuni dati (in genere i dati che "fossil scrub" rimuoverà). Se non è necessario eseguire il backup di tali dati, è sufficiente eseguire il backup sfruttando solo la replica. – Benoit